Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24

[Pekka Savola <[e-mail]>]

On Sun, 9 Mar 2003, Brian Haberman wrote:
> >    The scope of the unicast-prefix based multicast address MUST NOT
> >    exceed the scope of the unicast prefix embedded in the multicast
> >    address.
> > 
> > note: "embedded in the multicast address".  But as you should note here, 
> > an address (particularly _SSM_, which is really not derived from the 
> > unicast prefix) does not.
> 
> The intent was that the scope of the SSM group address would
> not exceed the scope of the SSM source address.  The scoped addr
> arch forwarding rules *WILL* prevent a scoped address from leaking
> out of the administrative zone.
> 
> The overall issue though is not SSM-specific.  

Yes and no: in ASM, the DR only checks that G is ok; not it must check 
that both S and G are ok.

> That is, the
> scoped addr arch is responsible for determining the forwarding
> issues around scoped addresses.  I don't see a need for putting
> any type of scoped address issues in the SSM doc.
...
> As stated above, I don't see a reason to deal with scoped addresses
> in the SSM arch doc.

I understand this argument and I agree with it, mostly: at this point, we
may end up doing some nasty things (in ipv6 w.g.) with scoped address
architecture anyway, so trying to specify everything in detail in the 
specs before we know we have to do it seems premature.

So, I can support putting considerations like these in the scoped address 
architecture document, but IMO, there *must* be a brief mention of the 
issues and a pointer in e.g. Security Considerations section.

> >>As stated above RFC 3306 does have restrictions on what the scope
> >>of the group address can be.
> > 
> > 
> > As above, I'm not sure how this applies to RFC3306 addresses which do not 
> > depend on the prefix, ie. SSM.
> 
> I consider the source address of an SSM group to be equivalent to
> the unicast prefix used in an RFC 3306 generated address.

One could consider so, but as was noted earlier, I didn't see it that way, 
and many others probably won't either -- unless clarified.

More work for scoped addrarch, I suppose.

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

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

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


_______________________________________________
ssm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm