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

[Dave Taht <[e-mail]>]

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

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.

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]