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

[Brian Haberman <[e-mail]>]

Pekka Savola wrote:
>>>==> (also a part of the main doc, but..) one thing I'd maybe like to see is
>>>how SSM is treated with non-global IPv6 addresses.  Perhaps it has to say
>>>something like that the scoping must also be done based on the rules for
>>>unicast addresses of S.  In particular, (S,G) = (fe80::1%eth0, ff3e::1) is
>>>clearly invalid outside of the link-local zone where it originated.
>>
>>So, today the document says this "Normal IPv6 multicast scope
>>boundaries are applied to traffic sent to an SSM destination address."
>>
>>I thought this was sufficient -- as I understand it, a router isn't
>>allowed to forward an SSM packet across a scope boundary of either the
>>source or the destination address.  I think this is exactly how scoped
>>unicast works (and how ASM works), so do we really need any special
>>rules for SSM?
> 
> 
> Perhaps Brian Haberman, as a co-author of scoped address architecture, can 
> comment on this.
> 
> You're right that this is not really SSM-specific except in one fashion:  
> sources indicate interest in (S,G) channels, not just G.  So, what if on a
> web page someone publishes a channel with (fe80::1, ff3e::1) -- or the
> same for site-local addresses?  This is one area which does seem 
> SSM-specific. 

Actually it is not SSM specific.  Someone could publish an FTP link
on a webpage that specifies FE80::5 as the target.  If you reach the
webpage using a global address, there is nothing that can be done
about it.

Also consider that the rules in RFC 3306 state that the scope of
the multicast address cannot exceed the scope of the unicast prefix
from which it derives.  Even though it is not specifically stated
for SSM, it applies.  So, an SSM channel cannot have a group address
that exceeds the scope of the unicast address.

>  
> 
>>>Another
>>>potential issue is whether the unicast scope must at least equal that of the
>>>multicast address.  There are also some other unicast scoping issues to
>>>consider, but they might make the those are rather complex and maybe not
>>>worth the effort.
>>
>>I thought about this and looked at the IPv6 default address selection
>>document (draft-ietf-ipv6-default-addr-select-09.txt) for guidance
>>when I last revved the document.
>>
>>My rationale for *not* saying that the unicast scope must be as large
>>as the multicast scope is that this restriction does not appear to be
>>required (as far as I can tell) for IPv6 unicast or IPv6 ASM, and I
>>didn't see a reason for SSM to be special in this regard.  On a host
>>with multiple addresses, I suppose we could say that the source
>>address selection rules of draft-ietf-ipv6-default-addr-select-09
>>probably SHOULD be followed when picking the SSM source, but again, I don't
>>really think this is an SSM-specific issue.
>>
>>But I'm open to ideas.
> 
> 
> The problem as above seems to be that the source address for a channel 
> needs to be published in some fashion.  Publication of non-unique (S,G) 
> may be a problem.  Of course, one could argue that this is not so much 
> different from publisting an admin-scoped ASM G..
> 
> I'm not sure what to think of this issue -- so other comments would be 
> useful.
>  

As stated above RFC 3306 does have restrictions on what the scope
of the group address can be.

> 
>>>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
>>>
>>>==> the prefix length is FF3x::/32, I think, must state here!
>>>
>>>Addresses in the
>>>range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM
>>>addresses, per [IPV6-UBM].  The treatment of a packet sent to such an
>>>invalid address is undefined -- a router or host MAY choose to drop such
>>>a packet.
>>>
>>>==> the above seem to be clearly wrong -- I see *nothing* in IPV6-UBM that 
>>>says so!?
>>
>>Ok, so you're right about this not being stated in IPv6-UBM.  It is
>>actually the combination of [IPV6-UBM] and [IPV6-MALLOC] that together
>>imply that these are invalid SSM addresses.  The problem is that
>>IPV6-MALLOC says that the 0x00000001 to 0x3fffffff must have P=0 and
>>T=0, but IPv6-UBM says that all SSM addresses must set P=1 and T=1.
>>This is the rationale for calling these invalid addresses.
>>
>>So perhaps this needs to be clarified in the document, then.
> 
> 
> It seems to me that this would imply that no such reserved range exists 
> for SSM?
> 
> This seems like an issue that we must be very careful of, so that no one 
> could say this document is trying to usurp either Proposed Standard.
> 
> Brian as an author for both can probably clarify at least on the intent.

Not sure I quite understand the issue.  The SSM range is to be
allocated out of FF3x::/96, however 3306 reserves the entire /32
for use later on with bigger group ID values.

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.

Brian

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