[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ssm] permanent ipv6 ssm addresses [was ...last call..]
[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 <bkhabs@nc.rr.com>
> Cc: Hugh Holbrook <holbrook@cisco.com>, ssm@ietf.org
>
> 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
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm