Re: [ssm] what to say about scoping for v6 [was ...last call...]

Pekka Savola <> Wed, 12 March 2003 21:25 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id QAA23664 for <>; Wed, 12 Mar 2003 16:25:21 -0500 (EST)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h2CLdRq17311 for; Wed, 12 Mar 2003 16:39:27 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h2CLdRO17308 for <>; Wed, 12 Mar 2003 16:39:27 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id QAA23632 for <>; Wed, 12 Mar 2003 16:24:50 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h2CLdGO17291; Wed, 12 Mar 2003 16:39:16 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h2CLc8O17174 for <>; Wed, 12 Mar 2003 16:38:08 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id QAA23528 for <>; Wed, 12 Mar 2003 16:23:28 -0500 (EST)
Received: from localhost (pekkas@localhost) by (8.11.6/8.11.6) with ESMTP id h2CLNQQ16561; Wed, 12 Mar 2003 23:23:26 +0200
Date: Wed, 12 Mar 2003 23:23:26 +0200
From: Pekka Savola <>
To: Brian Haberman <>
Subject: Re: [ssm] what to say about scoping for v6 [was ...last call...]
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 Wed, 12 Mar 2003, Brian Haberman wrote:
> >>How your SSM-enabled router will/would react now, or in 1-2 years is a 
> >>complete question mark.
> > 
> > 
> > Perhaps I'm not creative enough, but I can't imagine any
> > implementation of scoped addresses that would not apply scope limits
> > to both the source and destination.

Different unicast and multicast codepaths? Or..

> Neither can I.  In fact, that is one of the items in the scoped
> addressing architecture that everyone agrees on.  Both S & G have
> to be checked when a scoped boundary is encountered.

.. not *implementing* scoped address architecture at all while supporting 

I certainly don't want to require scoped addrarch for SSM implementation;  
moreover, I don't want to give users the expectation that using e.g.  
(fec0::1, ff3e::1) would just somehow magically get discarded somewhere
near the manually configured site border by SSM routers.

I see a lot of cases.  Most IPv6 routers today, as far as I've looked,
forward site-local source addresses quite nicely anywhere I want..
> > In fact, I would be ok with putting in text saying that for SSM joins
> > and data, the scope boundaries MUST be applied to the source address
> > in addition to the destination address.
> > 
> That is what the scoped addressing architecture already says.
> Do we need to repeat it?

I'd like a mention of why it is a problem better, and leaving the actual 
behaviour undefined or TBD in scoped addrarch.

> >>  Note that when forwarding or processing SSM, the scope of both S and G 
> >>  may have to be considered [SCOPED-ARCH]; in particular, if the unicast 
> >>  scope of S is smaller than respective multicast scope of G, the packets 
> >>  might end up forwarded outside of the scope of S.  Therefore, limited 
> > 
> > 
> > I would prefer not to say this because I think it is not likely to
> > ever be allowed.  

I agree here: it's not likely be allowed, but the *security 
considerations* part of it is that it *does* happen when/if scoped 
addrarch hasn't been implemented in the designated routers etc. -- this 
was a balance between specification status and operational reality.

> > I'd be happy saying just that "scopes should not be
> > used as a security mechanism..."  and leaving it at that.  

If a variation of that where it's explicit that it applies to the source 
address is added, that's ~ok.

> > I think
> > it's overkill to say that limited scope addresses must be avoided with
> > SSM, because I think they work fine as long as boundaries are applied
> > to the source as well.

(For what it's worth, I was referring to unicast S scoped *only*, if it 
makes any difference.)

The point is that I'm having some doubts whether boundaries *are* actually
applied to the source..

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