Re: [ssm] what to say about scoping for v6 [was ...last call...]
Brian Haberman <bkhabs@nc.rr.com> Tue, 11 March 2003 14:23 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20314 for <ssm-archive@odin.ietf.org>; Tue, 11 Mar 2003 09:23:44 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BEbCa01462 for ssm-archive@odin.ietf.org; Tue, 11 Mar 2003 09:37:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BEbCO01451 for <ssm-web-archive@optimus.ietf.org>; Tue, 11 Mar 2003 09:37:12 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20301 for <ssm-web-archive@ietf.org>; Tue, 11 Mar 2003 09:23:12 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BEZ9O01156; Tue, 11 Mar 2003 09:35:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BEYbO01095 for <ssm@optimus.ietf.org>; Tue, 11 Mar 2003 09:34:37 -0500
Received: from ms-smtp-03.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20253 for <ssm@ietf.org>; Tue, 11 Mar 2003 09:20:37 -0500 (EST)
Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2BELNHE007428; Tue, 11 Mar 2003 09:21:33 -0500 (EST)
Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Mar 2003 09:09:30 -0500
Message-ID: <3E6DEDC1.7050301@nc.rr.com>
Date: Tue, 11 Mar 2003 09:08:01 -0500
From: Brian Haberman <bkhabs@nc.rr.com>
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: holbrook@cisco.com
CC: Pekka Savola <pekkas@netcore.fi>, ssm@ietf.org
Subject: Re: [ssm] what to say about scoping for v6 [was ...last call...]
References: <20030311073008.5ECC310B7A7@holbrook-laptop.cisco.com>
In-Reply-To: <20030311073008.5ECC310B7A7@holbrook-laptop.cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ssm-admin@ietf.org
Errors-To: ssm-admin@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Hugh Holbrook wrote: > [ ... Snipping just the thread on scoping for ssm ] > > My comments inline... > > >>Date: Mon, 10 Mar 2003 08:01:49 -0500 >>From: Brian Haberman <bkhabs@nc.rr.com> >>Cc: Hugh Holbrook <holbrook@cisco.com>, ssm@ietf.org >> >>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. >>> > > > A pointer to what? draft-ietf-ipngwg-scoping-arch-04.txt? > That would be the beast. RFC 3484 references it when discussing the issue of scope within the source address selection policy. It can be an informative reference here. > >>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. > > > So I'm trying to convert this discussion about scoping to concrete > text. Here's what the doc currently says about v6 scoped addresses. > > For IPv6, administratively scoped SSM addresses are created by choosing > an appropriate scope identifier for the SSM destination address. Normal > IPv6 multicast scope boundaries are applied to traffic sent to an SSM > destination address. > > I note that this paragraph is confusing because it says you can make a > "scoped SSM addresses" when what it should say is "scoped SSM channel > addresses". Here is proposed text to incorporate what I think Pekka > is suggesting. > > For IPv6, administratively scoped SSM channel addresses are created > by choosing an appropriate scope identifier for the SSM destination > address. Normal IPv6 multicast scope boundaries are applied to > traffic sent to an SSM destination address, including any relevant > boundaries applied to both the source and destination address. > > Question 1: Do you accept the above text? I'm not sure I captured the > issue, so I'd appreciate a better alternative if you see one. I am ok with it, but I didn't raise the issue either. So, I would like Pekka's assessment before we declare victory. :) > > Question 2: If not, is there an appropriate reference for "Normal IPv6 > multicast scope boundaries," or is it preferable to intentionally > leave the document without a reference? I don't see a problem with having an informative reference for the scoped addr arch doc. > > Question 3: Should we add text to clarify the "embedded address" text > in RFC3306. I can think of three options: > > Either prohibit it: > > For IPv6, senders MUST ensure that the scope of a channel > destination address does not exceed the scope of the channel source > address. > > Or allow it: > > For IPv6, the scope of a channel destination address MAY exceed the > scope of the channel source address. Normal forwarding rules for > scoped traffic apply to a packet sent to such a channel. Normal > multicast scoping rules apply for any routing protocol messages > (e.g., "joins") referring to such a channel. > > Or say nothing: > > I am inclined to do the latter, and I think this is what both of you > are saying. Am I right? > I agree, the latter works for me. Should we add a reference to RFC 3484 as a note on how the address selection could occur? Brian _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm
- [ssm] another last call for draft-ietf-ssm-arch -… Hugh Holbrook
- Re: [ssm] another last call for draft-ietf-ssm-ar… Pekka Savola
- Re: Re: [ssm] another last call for draft-ietf-ss… Hugh Holbrook
- Re: Re: [ssm] another last call for draft-ietf-ss… Pekka Savola
- Re: [ssm] another last call for draft-ietf-ssm-ar… Brian Haberman
- Re: [ssm] another last call for draft-ietf-ssm-ar… Pekka Savola
- Re: [ssm] another last call for draft-ietf-ssm-ar… Brian Haberman
- Re: [ssm] another last call for draft-ietf-ssm-ar… Pekka Savola
- Re: [ssm] another last call for draft-ietf-ssm-ar… Brian Haberman
- Re: Re: Re: [ssm] another last call for draft-iet… Hugh Holbrook
- [ssm] what to say about scoping for v6 [was ...la… Hugh Holbrook
- [ssm] permanent ipv6 ssm addresses [was ...last c… Hugh Holbrook
- Re: [ssm] permanent ipv6 ssm addresses [was ...la… Brian Haberman
- Re: [ssm] another last call for draft-ietf-ssm-ar… Brian Haberman
- Re: [ssm] what to say about scoping for v6 [was .… Brian Haberman
- Re: Re: [ssm] permanent ipv6 ssm addresses [was .… Hugh Holbrook
- Re: [ssm] what to say about scoping for v6 [was .… Pekka Savola
- Re: Re: [ssm] what to say about scoping for v6 [w… Hugh Holbrook
- Re: [ssm] what to say about scoping for v6 [was .… Brian Haberman
- Re: Re: [ssm] what to say about scoping for v6 [w… Pekka Savola
- Re: [ssm] what to say about scoping for v6 Hitoshi Asaeda
- Re: Re: Re: [ssm] what to say about scoping for v… Hugh Holbrook
- Re: [ssm] what to say about scoping for v6 Pekka Savola
- Re: [ssm] what to say about scoping for v6 [was .… Brian Haberman
- Re: [ssm] what to say about scoping for v6 [was .… Pekka Savola
- Re: Re: [ssm] what to say about scoping for v6 [w… Hugh Holbrook
- Re: Re: [ssm] what to say about scoping for v6 [w… Pekka Savola
- Re: Re: [ssm] another last call for draft-ietf-ss… Hugh Holbrook