Re: Re: [ssm] permanent ipv6 ssm addresses [was ...last call..]
Hugh Holbrook <holbrook@cisco.com> Wed, 12 March 2003 07:24 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 CAA18217 for <ssm-archive@odin.ietf.org>; Wed, 12 Mar 2003 02:24:09 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C7bxm20382 for ssm-archive@odin.ietf.org; Wed, 12 Mar 2003 02:37:59 -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 h2C7bxO20377 for <ssm-web-archive@optimus.ietf.org>; Wed, 12 Mar 2003 02:37:59 -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 CAA17681 for <ssm-web-archive@ietf.org>; Wed, 12 Mar 2003 02:23:37 -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 h2C7bIO19975; Wed, 12 Mar 2003 02:37:18 -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 h2C7ZmO19545 for <ssm@optimus.ietf.org>; Wed, 12 Mar 2003 02:35:48 -0500
Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15405 for <ssm@ietf.org>; Wed, 12 Mar 2003 02:21:26 -0500 (EST)
Received: from holbrook-laptop.cisco.com (sjc-vpn3-863.cisco.com [10.21.67.95]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2C7NWhs004336; Tue, 11 Mar 2003 23:23:33 -0800 (PST)
Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 40B0E10B7A7; Tue, 11 Mar 2003 23:19:09 -0800 (PST)
From: Hugh Holbrook <holbrook@cisco.com>
To: Brian Haberman <bkhabs@nc.rr.com>
Cc: holbrook@cisco.com, Pekka Savola <pekkas@netcore.fi>, ssm@ietf.org
In-reply-to: <3E6DDDDD.2050908@nc.rr.com>
Subject: Re: Re: [ssm] permanent ipv6 ssm addresses [was ...last call..]
Reply-To: holbrook@cisco.com
Message-Id: <20030312071909.40B0E10B7A7@holbrook-laptop.cisco.com>
Date: Tue, 11 Mar 2003 23:19:09 -0800
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>
Cool, thanks. I've made both of these changes to my working copy. -Hugh > Date: Tue, 11 Mar 2003 08:00:13 -0500 > From: Brian Haberman <bkhabs@nc.rr.com> > Cc: Pekka Savola <pekkas@netcore.fi>, ssm@ietf.org > > Hugh Holbrook wrote: > > [snipping just the thread on allocating permanent ipv6 addresses] > > > > Thanks for your input, Pekka and Brian. > > > > Exactly -- the idea is that an application that requires, for some > > reason, that the same channel destination address be used on all hosts > > providing that channel would be allocated from 0x40000000-0x7fffffff. > > Any other channel destination addresses, regardless of lifetime, must > > come from the 0x80000000-0xffffffff space. > > > > Section 4.3 states that a host OS SHOULD provide an interface to > > allocate a random address, and that this information must be stored in > > a database that persists across reboots. The idea is that this is the > > mechanism that an application or user uses to allocate an SSM address. > > > > I think this is probably already clear, but I want to underscore the > > importance of using random allocation for SSM addresses. It is not a > > good idea (and is in fact specifically disallowed in section 4.3) for > > a host, host application, or host OS, to deterministically pick > > FF3x::1 or FF3x::2, or *any* fixed value as the channel destination > > address on all hosts for some application -- because of the link-layer > > collision issue. > > > > -------------------------------- > > > > So to summarize on the text changes, the only textual change I > > currently think is warranted is to clarify in 4.3 and in the IANA > > Considerations section the use of the 4000:0000 to 7fff:ffff > > > > In 4.3, change this: > > > > The SSM destination address 232.0.0.0 is reserved, and systems MUST NOT > > send datagrams with destination address of 232.0.0.0. The address range > > 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. The > > IPv6 SSM address range FF3x::/32 is reserved for IANA allocation. > > > > to correctly call out the 0x4000000-7fffffff range. > > > > The SSM destination address 232.0.0.0 is reserved, and systems MUST NOT > > send datagrams with destination address of 232.0.0.0. The address range > > 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. SSM > > destination addresses in the range FF3x::4000:0000 through > > FF3x::7FFF:FFFF are similarly reserved for IANA allocation. > > Seems reasonable to me. > > > > > I'm not sure where the FF3x::/32 came from, but I think it is a > > vestige of an earlier revision that was less clear on the /96 vs /32 > > distinction. > > I agree. RFC 3306 reserves the entire /32 so that group IDs can > grow beyond the lower 32 bits of the group address. RFC 3307 then > states that allocations must be done out of the /96 (for the time > being). > > > > > And a similar fix IANA Considerations. > > > > Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 > > addresses with prefix FF3x:: are reserved for services with wide > > applicability that either require or would strongly benefit if all > > hosts used a well-known SSM destination address for that service. > > > > to read > > > > Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 > > addresses in the range FF3x:4000:0000 to FF3x::7FFF:FFFF are > > reserved for services with wide applicability that either require or > > would strongly benefit if all hosts used a well-known SSM > > destination address for that service. > > > > Any objections to these changes? > > I don't have any objections. > > Brian > > _______________________________________________ > ssm mailing list > ssm@ietf.org > https://www1.ietf.org/mailman/listinfo/ssm _______________________________________________ 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