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

[Hugh Holbrook <[e-mail]>]

[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.

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.

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?

-Hugh


> Date: Mon, 10 Mar 2003 08:01:49 -0500
> From: Brian Haberman <[e-mail]>
> Cc: Hugh Holbrook <[e-mail]>, [e-mail]
> 
> Pekka Savola wrote:
> > On Sun, 9 Mar 2003, Brian Haberman wrote:

> >>>>Now, RFC 3307 reserves 0x00000001 to 0x3FFFFFFF for use with
> >>>>permanently allocated IPv6 multicast addresses.  This is for
> >>>>consistency with permanent IPv4 multicast addresses.  That
> >>>>means that T=0 in the flags field.  I would expect that SSM
> >>>>applications would allocate group IDs out of the 0x80000000 to
> >>>>0xFFFFFFFF range for SSM channels.
> >>>
> >>>But RFC3306 addresses, including SSM, *MUST* have T=1, so one could argue 
> >>>that the reservation does not hold.
> >>
> >>Not sure what you mean here.  3307 is very explicit in what IANA
> >>is reserving for group IDs.
> > 
> > 
> > 3307 says:
> > 
> > 4.1  Permanent IPv6 Multicast Addresses
> > 
> >    Permanent multicast addresses, like those defined in [RFC 2375], are
> >    allocated by IANA.  These addresses will be assigned with group ID's,
> >    in the range of 0x00000001 to 0x3FFFFFFF, on an Expert Review basis.
> > 
> >    Multicast addresses assigned by IANA MUST have the T bit set to 0 and
> >    the P bit set to 0.
> > 
> > ==> the last sentence does not hold for SSM; the IANA considerations 
> > section itself is quite explicit.
> > 
> 
> SSM addresses are not restricted to the completely dynamic addresses.
> An SSM app could request a permanent group ID as defined in section
> 4.2.
>
> > 
> >>>IMO, reserving 0x8... to 0xf for apps would be a bad decision.  SSM is
> >>>_source_ specific.  It makes very much sense for apps/users to use as
> >>>simple addresses as possible, like FF3X::1, FF3X:::2, ..., *not* like 
> >>>FF3X::8000:0001, FF3X::8000:0002, etc.
> >>
> >>But there is a bigger issue.  One of the goals of 3307 is to help
> >>prevent collisions at the layer-2 mapping of group addresses.  By
> >>having separate 32-bit ranges for the group IDs, it is possible to
> >>minimize the number of collisions that occur at the MAC layer.
> > 
> > 
> > Ok, I can accept that, I think.
> > 
> > 
> >>>There doesn't seem to be need for this kind of address reservation is
> >>>necessary for SSM; if, for some particular reason, reservation is
> >>>necessary, it would seem to be better done at the end of the address
> >>>space.
> >>>
> >>
> >>But, the end of the address range collides with existing assignments
> >>already delegated in RFC 2375.  That is why 3307 uses the low end of
> >>the range for permanent group IDs.
> > 
> > 
> > Ok; so, if a user manually configures an SSM address to be used, he must
> > use ones from the dynamic range?  (even though the dynamicity is
> > arguable.)
> > 
> 
> As noted above, the user could request a permanent group ID for the
> application.
_______________________________________________
ssm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm