Re: [ssm] permanent ipv6 ssm addresses [was ...last call..]

Brian Haberman <bkhabs@nc.rr.com> Tue, 11 March 2003 13:06 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 IAA18155 for <ssm-archive@odin.ietf.org>; Tue, 11 Mar 2003 08:06:30 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BDJxO28686 for ssm-archive@odin.ietf.org; Tue, 11 Mar 2003 08:19: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 h2BDJxO28683 for <ssm-web-archive@optimus.ietf.org>; Tue, 11 Mar 2003 08:19: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 IAA18131 for <ssm-web-archive@ietf.org>; Tue, 11 Mar 2003 08:05:59 -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 h2BDJSO28585; Tue, 11 Mar 2003 08:19:28 -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 h2BDIOO28447 for <ssm@optimus.ietf.org>; Tue, 11 Mar 2003 08:18:24 -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 IAA18039 for <ssm@ietf.org>; Tue, 11 Mar 2003 08:04:24 -0500 (EST)
Received: from mail3.nc.rr.com (fe3 [24.93.67.50]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2BD5MHG023756; Tue, 11 Mar 2003 08:05:24 -0500 (EST)
Received: from nc.rr.com ([63.109.132.2]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Mar 2003 07:58:07 -0500
Message-ID: <3E6DDDDD.2050908@nc.rr.com>
Date: Tue, 11 Mar 2003 08:00:13 -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] permanent ipv6 ssm addresses [was ...last call..]
References: <20030311080214.C911910B7A7@holbrook-laptop.cisco.com>
In-Reply-To: <20030311080214.C911910B7A7@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 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