Re: [MBONED] ipv4 multicast address ranges, actual usage.

[David Farmer <[e-mail]>]

On Wed, Dec 18, 2019 at 5:16 PM Dave Taht <[e-mail]> wrote:

> On Wed, Dec 18, 2019 at 3:06 PM Leonard Giuliano <[e-mail]>
> wrote:
> >
> >
> > Well articulated, Jake.
>

+1


> > Dave- Keep in mind, outside of 224/8, all the space is derived and
> > designed to *reduce* wasted allocations.  That is, 239/8 is basically
> like
> > RFC1918 for mcast and to be used to prevent use of public space for
> > internal network usage.  233/8 and 234/8 were designed to end the static
> > IANA allocations for mcast addressing.  And 232/8 will hopefully make all
> > the other allocations unnecessary.
>
> I buy that 232/8 and 239/8 are off-limits, but I did want to learn
> more about the other allocations
> 233/8 - 238/8. Thank you for the updates on 233 and 234, also, but it
> does sound to me like those can be retired.
>

draft-ietf-mboned-deprecate-interdomain-asm effectively deprecates the use
of 233/8, 234/8, and 224/8 as well, in an interdomain context.
However, their use remains completely valid in an intradomain context,
therefore 233/8 and 234/8 should probably remain reserved for multicast
use, for several years at least. Maybe someday 233/8 and 234/8 could
be deprecated, but doing so now seems a little premature.


> Do you think anybody would notice if 225/8 - 231/8 became unicast? We
> have scanned the source code of the world and come up empty here.
>

Source code isn't the only place where multicast addresses are used. I'll
note reserved multicast addresses are used frequently in the documentation
for multicast, especially in examples documenting the translation of
multicast IP addresses to multicast MAC addresses, such a 225.0.0.1,
225.1.1.1, 226.0.0.1, 226.1.1.1, etc... Try searching for these addresses,
you will find them all over the place. There will be confusion caused by
obsolete documentation that assumes 224.0.0.0/4 are all multicast IP
addresses. I'm not saying they can't be reused, but the amount of obsolete
documentation created by such a change shouldn't be taken lightly. There
are 25+ years of books and other documentation that will become obsolete by
this change, literally, every book discussing IP addressing in every
library around the world will likely become obsolete.

this is the linux patch.
>
> static inline bool ipv4_is_multicast(__be32 addr)
> {
> - return (addr & htonl(0xf0000000)) == htonl(0xe0000000);
> + if((addr & htonl(0xf0000000)) == htonl(0xe0000000))
> + return !((htonl(addr) >= 0xe1000000) &&
> + (htonl(addr) < 0xe8000000));
> + return 0;
> }
> >
> >
> > On Wed, 18 Dec 2019, Holland, Jake wrote:
> >
> > | Hi Dave,
> > |
> > | I think the framing of "actual usage" isn't quite the best way to look
> > | at it.
> > |
> > | Much like ECN and IPv6, there were some hurdles and it took longer than
> > | anyone hoped, but it's not dead yet, the reasons to use it are still
> > | with us, and there has been recent movement that's giving some cause
> > | for hope that the next few years might see a much expanded deployment.
> > | (Any day now...)
> > |
> > | With that said:
> > |
> > | 232/8 is extremely important, from my point of view.  I'd also be
> > | slightly reluctant to give up 233 or 239, though I care much less
> > | about them than 232.
> > |
> > | The rest of the space I have no attachment to.
> > |
> > | Reasons:
> > |
> > | ASM for interdomain is in process of getting deprecated:
> > |
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-mboned-deprecate-interdomain-asm-03__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdO88geEU$
> > |
> > | But SSM is still the way of the future, with any luck, and the 232/8
> > | allocation is critical to its usability.  (The flexibility on 233 and
> > | 239 that makes them candidates for extra SSM space is also the biggest
> > | part of what I like about them.)
> > |
> > | My deployment is still pretty limited today, but a couple of my recent
> > | drafts are trying to get it over a few final hurdles:
> > |
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-10__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdj2arhgA$
> > |
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-jholland-mboned-dorms-00__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdGwB4rSI$
> > | (plus a couple of augmentations to dorms that try to enable a safe
> > | MulticastReceiver W3C API.)
> > |
> > | Once these hurdles are solved, it's my sincere hope to start rolling
> out
> > | interdomain usage of 232/8 at as big a scale as I can muster.  (I have
> a
> > | few trickles available today, but "actually used" for interdomain
> traffic
> > | is still a bit of a stretch.)
> > |
> > | Provided that SSM is left alone, I have no objections that are
> > | specifically about reassigning unused multicast address space.  (For
> > | this venue, I'll leave aside any questions about the overall wisdom of
> > | the project... :) )
> > |
> > | Best,
> > | Jake
> > |
> > |
> > | On 2019-12-18, 13:02, "Dave Taht" <[e-mail]> wrote:
> > |
> > | On Wed, Dec 18, 2019 at 12:49 PM Leonard Giuliano <[e-mail]>
> wrote:
> > | >
> > | > Dave,
> > | >
> > | > Take a look at RFC6308 and RFC 5771 for an overview of multicast
> > | > addressing.  But to summarize, 232/8 is reserved for SSM (RFC4607).
> > | > 233/8 is reserved for GLOP (RFC3180).  234/8 is reserved for
> > | > Unicast-Prefix-Based Allocation (RFC6034).  239/8 is reserved for
> admin
> > | > scoped allocation (RFC2365).
> > |
> > | I had already reviewed those pretty thoroughly in writing the drafty
> draft.
> > |
> > | The question was:
> > |
> > | "to what extent are the various allocations in the 232/8 to 238/8
> > | range actually used today, and for
> > | what?"
> > |
> > | The "for what" portion of the question was: what applications today
> > | actually use GLOP? or RFC6038? or SSM?
> > |
> > | What mailing list or list might have some answers to the actual usage
> > | of these ranges?
> > |
> > | As best as I can tell actual multicast usage of ipv4 is down to the
> > | dozens of applications (all with allocated ip address in 224 or 239 -
> > | with mdns topping the list.
> > | >
> > | > Hope this helps,
> > | > Lenny
> > | >
> > | > On Wed, 18 Dec 2019, Dave Taht wrote:
> > | >
> > | > | As a few people know I've been working (quixotically) in my spare
> time
> > | > | towards making more of the IPv4 address space generally usable.
> We've
> > | > | landed patches for 0/8 in linux, and 240/4 had already been mostly
> > | > | made working a decade back.
> > | > |
> > | > | Now we come against a harder problem, in that 1) - a vast swath of
> > | > | multicast address space was never allocated for anything by iana
> > | > | (225/8-231/8) and 2) 232/8-238/8 appears severely underutilized.
> Only
> > | > | portions of 224/8 and 239/8 seem to have any usage at all.
> > | > |
> > | > | We've successfully made that first formerly multicast range pretty
> > | > | generally usable in a string of patches on our github for various
> oses
> > | > | and routing daemons. https://github.com/dtaht/unicast-extensions
> - and
> > | > | for a drafty draft of a draft internet draft, see:
> > | > |
> https://github.com/dtaht/unicast-extensions/blob/master/rfcs/draft-gilmore-taht-v4uniext.txt
> > | > |
> > | > | My question today, though (lacking finding a mailing list more
> > | > | suitable than this - is there one?), is to what extent are the
> various
> > | > | allocations in the 232/8 to 238/8 range actually used today, and
> for
> > | > | what?
> > | > |
> > | > |
> > | > | --
> > | > | Make Music, Not War
> > | > |
> > | > | Dave Täht
> > | > | CTO, TekLibre, LLC
> > | > |
> https://urldefense.com/v3/__http://www.teklibre.com__;!!NEt6yMaO-gk!ToLvTOd6t8dQ1-sH4XmghgDQrcb4JVFwnxuPeA-h4IwQmqxaVhSKHdAeEcHC_4g$
> > | > | Tel: [phone]
> > | > |
> > | > | _______________________________________________
> > | > | MBONED mailing list
> > | > | [e-mail]
> > | > |
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!ToLvTOd6t8dQ1-sH4XmghgDQrcb4JVFwnxuPeA-h4IwQmqxaVhSKHdAe8DjJ-24$
> > | > |
> > |
> > |
> > |
> > | --
> > | Make Music, Not War
> > |
> > | Dave Täht
> > | CTO, TekLibre, LLC
> > |
> https://urldefense.com/v3/__http://www.teklibre.com__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdRWcS0UY$
> > | Tel: [phone]
> > |
> > | _______________________________________________
> > | MBONED mailing list
> > | [e-mail]
> > |
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdM-rBNQE$
> > |
> > |
>
>
>
> --
> Make Music, Not War
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: [phone]
>
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned
>


-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================