[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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