Re: [pim] [MBONED] IPv4 Multicast address ranges

[Leonard Giuliano <[e-mail]>]

<resending with PIM, et al, included, as they got dropped along the way in 
this sub-thread>

I think this is already doable today.  That is, SSM range is defined as 
232/8, and "SSM-only" behavior is supposed to be guaranteed there (ie, no 
(*,g), no shared trees, no pim registers, no MSDP SAs for these groups). 
The rest of 224/4 is not necessarily "ASM-only".  After all, SSM is really 
just a subset of ASM, so I'm not sure what "ASM-only" is- (s,g) joins 
happily work there, and beyond the receiver LAN, SSM is just (s,g) joins. 
So you can certainly do SSM outside of 232/8 today, you just get no 
guarantee that it will be pure SSM service (ie, there might appear (*,g), 
shared trees, pim registers, MSDP SAs for these groups).

That said, if you do want pure SSM service outside of 232/8, it should be 
configurable to specify other SSM-only ranges.

As for the scoping sematics, I think it could all be really simplified. 
238/8 is effectively private address space, the RFC1918 equiv, for mcast. 
This range is not allowed to be routable on the global Internet, so what 
goes on within your castle (or confed of non-Internet-connected castles) 
is your business.  But I think this type of address semantics is certainly 
outside the scope of protocol spec.



On Wed, 3 Jan 2024, Stevens, Jim A Collins wrote:

| 
| 
| Hitoshi discussed the issue of allocating (or chopping) the IP multicast 
| range.  I agree with his recommendation that SSM should be useable in 
| more ranges, especially the GLOP and Unicast-Prefix blocks, than just 
| the SSM Block.  It is not clear to me however, whether there are any 
| blocks that should ONLY be ASM.
| 
| > -----Original Message-----
| > Date: Wed, 3 Jan 2024 01:28:30 +0900
| > From: Hitoshi Asaeda <[e-mail]>
| > To: Brian Haberman <[e-mail]>
| 
| > Dependency or relation between protocol designs and operational issues (or
| > policies) should be always minimized.
| > Protocol behavior should not be solidly relies on the address range.
| >
| > IP multicast has a long history for allocating (or chopping) its address ranges.
| > We had adopted complicated "address scopes" such as administrative/site-
| > local/organization-local scope... How we can interact with SSM range and
| > them?
| > I've just remembered GLOP. How SSM and GLOP can be interacted with?
| > One may deduce, no need to interact with them, use SSM range.
| > Then what address ranges are obsolete today? What range should be used
| > now? Is its decision persistent?
| > Such a dirty hack or patch work is not sustainable for designing protocols.
| >
| > What I'm saying here may be a bit too conceptual. So, please ignore the points
| > if people agree to relying on the SSM range. However, even so, I guess the
| > following point must be taken into account.
| > Section 2 in RFC4604 says;
| >    A host or router may be configured to apply SSM semantics to
| >    addresses other than those in the IANA-allocated range.  The GMP
| >    module on a host or router SHOULD have a configuration option to set
| >    the SSM address range(s).  If this configuration option exists, it
| >    MUST default to the IANA-allocated SSM range.  The mechanism for
| >    setting this configuration option MUST at least allow for manual
| >    configuration.  Protocol mechanisms to set this option may be defined
| >    in the future.
| > I think this paragraph implies that applications that want to invoke SSM
| > services can use any multicast address range.
| > If RFC4604 should be the normative reference, RFC4604 itself must be also
| > revised.
| 
| 
| While on the topic multicast blocks, I am confused on IPv4 scoped multicast addresses and  Relative Addresses used with Scoped Multicast Addresses as defined by RFC 5771, RFC2365, and described in https://urldefense.com/v3/__https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml*multicast-addresses-13__;Iw!!NEt6yMaO-gk!B8bkjhuJ6Z0_9tvRa4juQ--C5u0v9Q3LzOW1ZNJxeWihY-jxlZh4JnnpICwa0AYIhb16mQXsOwtVi_Bw9jruIoXj9K6RfQ$
| 
| RFC 2365 Partitions the administratively scoped IPv4 multicast spaces in sections 6 & 8 and seems to imply that that there could be 2 to 7 possible IPv4 scoped blocks (depending upon how you read sections 6 & 8) while RFC 5771 and IANA multicast address Scoped Multicast Ranges only mention 1 scoped address block for organization-local scope.
| 
| RFC 2365 section 9, RFC 10.1.1, and IANA multicast address Relative Addresses used with Scoped Multicast Addresses mentioned that the upper /24 of each scoped block is reserved for relative assignments  The discussion in RFC 2365 section 9 explicitly states that the "  The high order /24 in every scoped region is reserved for relative assignments."  This implies more than one scoped region.
| 
| So,  how many scoped blocks are there?  And what are they?  I presume that based upon RFC 5771 being newer than RFC 2365 that there is only 1 - especially since IANA only shows
|     235.0.0.0-238.255.255.255   Reserved        [RFC5771]
|     239.0.0.0-239.255.255.255   Organization-Local Scope        [RFC2365]
| 
| If an RFC (I presume an informational or best practice RFC) is being prepared to discuss and described IPv4 multicast, then I think it should address scoped blocks (how many are they are what are they) and relative offsets.
| 
| 
| Going back to Hitoshi's suggestion that SSM should be usable in more than just the SSM block space, RFC 4607 section 4.3 and IANA multicast address Source-Specific Multicast Block state that 232.0.1.0-232.255.255.255 is Reserved for local host allocation.  This seems similar to the 239.0.0.0-239.255.255.255 Organization-Local Scope except allocated only to SSM while  239.0.0.0-239.255.255.255     Organization-Local Scope can be allocated to ASM (and SSM?)
| 
| 
| Aside - by the way, RFC 5771 section 10.1.1 on relative offsets starts with the following sentence: "The relative offsets [RFC2365] are used to ensure that a service can be located independent of the extent of the enclosing scope (see [RFC3180] for details)."  The reference to RFC2365 makes sense.  However, the reference to RFC3180 on GLOP does not.   Does anyone know why the reference to RFC 3180?  Should it reference a different RFC?  Or perhaps it should be removed?   This seems like a potential Errata for RFC 3180. Feedback from group?
| 
| 
| Jim Stevens
| 
| _______________________________________________
| MBONED mailing list
| [e-mail]
| https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!B8bkjhuJ6Z0_9tvRa4juQ--C5u0v9Q3LzOW1ZNJxeWihY-jxlZh4JnnpICwa0AYIhb16mQXsOwtVi_Bw9jruIoWGCMiQ7A$
|