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

[Brian Haberman <[e-mail]>]

Pekka Savola wrote:
> 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.
> 

Actually, the DR has to check both S and G to ensure that it does
not send a PIM Join across a scope zone boundary regardless of it
being ASM or SSM.  There was some text in the original PIM for v6
draft a long time ago.

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

Agreed. :)

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

I don't see a problem with doing that.  The security section can mention
the issue and say that it is out of scope for this doc and is being
addressed elsewhere.

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

Long-term it should be fixed in a revision of 3306.  Near-term we
could add text to this doc in section 4.3 clarifying the allocation
issue on scopes.

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

Brian

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