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

From: Dave Taht <[email-masked]>
Date: Wed, 18 Dec 2019 12:10:30 -0800

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
http://www.teklibre.com
Tel: 1-831-435-0729

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 18 Dec 2019 12:48:58 -0800

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

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: 1-831-435-0729
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!ToLvTOd6t8dQ1-sH4XmghgDQrcb4JVFwnxuPeA-h4IwQmqxaVhSKHdAe8DjJ-24$ 
|

---

From: Dave Taht <[email-masked]>
Date: Wed, 18 Dec 2019 13:01:28 -0800

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

-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

---

From: John Kristoff <[email-masked]>
Date: Wed, 18 Dec 2019 16:04:15 -0600

On Wed, 18 Dec 2019 21:01:28 +0000
Dave Taht <[email-masked]> wrote:

> range actually used today, and for what?"
> 

I think IETF RFC 6308 is the correct reference.

I can only tell you that we (DePaul AS 2013) no longer use any
IP multicast addresses outside of the organization local scope block
239.192.0.0/14. We used to have some applications uses our associated
GLOP prefix, but those are long gone and in fact we've ceased all
inter-AS IP multicast connectivity as of a few years ago.

I also happen to know Northwestern (AS 103) no longer distributes C-SPAN
onto the multicast-enabled Internet and hasn't for a long time, that
was using GLOP addressing.  One of the few R&E Internet-wide
applications I even recall hearing of that may have be in one of these
prefixes is some sort of oceanic-related project.

Not a lot of evidence of much, but hopefully small anecdotes are better
than silence.

John

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 18 Dec 2019 14:18:54 -0800

Previously, I would say 233/8 was probably the most validly used block for 
ASM traffic.  234/8 was useful for those sources that didn't have their 
own AS#, but most of the players on the MBONED who do source did have an 
AS#, so I suspect it never got wide usage.

Going forward, 232/8 should be the widest used block as SSM has been the 
recommended model for interdomain mcast.

Last year, William Zhang wrote a script to curate all the content on the 
MBONE.  His results for all the mcast streams with >5pps can be found 
here:

https://raw.githubusercontent.com/willzhang05/senior-research/master/logs/results.txt

Essentially, this looked at active multicast streams on the I2 Looking 
Glass (https://routerproxy.wash2.net.internet2.edu/routerproxy/).

| On Wed, Dec 18, 2019 at 12:49 PM Leonard Giuliano <[email-masked]> 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: 1-831-435-0729
| > |
| > | _______________________________________________
| > | MBONED mailing list
| > | [email-masked]
| > | 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!W0hgHVMJLatcKw6yFET8wtPoL5C-Tj6-d0UDjHqOKeo7pttN6GAamhtiVuKOj08$ 
| Tel: 1-831-435-0729
|

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 18 Dec 2019 22:55:53 +0000

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://tools.ietf.org/html/draft-ietf-mboned-deprecate-interdomain-asm-03

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://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-10
https://tools.ietf.org/html/draft-jholland-mboned-dorms-00
(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" <[email-masked]> wrote:

The question was:

-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 18 Dec 2019 15:06:44 -0800

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.

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" <[email-masked]> wrote:
| 
| On Wed, Dec 18, 2019 at 12:49 PM Leonard Giuliano <[email-masked]> 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: 1-831-435-0729
| > |
| > | _______________________________________________
| > | MBONED mailing list
| > | [email-masked]
| > | 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: 1-831-435-0729
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdM-rBNQE$ 
| 
|

---

From: Dave Taht <[email-masked]>
Date: Wed, 18 Dec 2019 15:16:09 -0800

> 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;
}

-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

---

From: David Farmer <[email-masked]>
Date: Thu, 19 Dec 2019 08:41:18 -0600

> On Wed, Dec 18, 2019 at 3:06 PM Leonard Giuliano <[email-masked]>

+1

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

> 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.
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-mboned-deprecate-interdomain-asm-03__;!!NEt6yMaO-gk!RlZVVsFmvI2wdvncPQPyASqr6B46tqgFJJ79SMTgIx93uDo4JS38PyGdO88geEU$
> > |
> 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$
> https://urldefense.com/v3/__http://www.teklibre.com__;!!NEt6yMaO-gk!ToLvTOd6t8dQ1-sH4XmghgDQrcb4JVFwnxuPeA-h4IwQmqxaVhSKHdAeEcHC_4g$
> 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: 1-831-435-0729
> > |
> 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: 1-831-435-0729
>

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

---

From: Leo Vegoda <[email-masked]>
Date: Thu, 19 Dec 2019 17:29:22 +0000

On 12/18/19, 3:16 PM, "MBONED on behalf of Dave Taht" <[email-masked] on behalf of [email-masked]> wrote:

[...]

> have scanned the source code of the world and come up empty here.

I think the amount of attention required would vary depending on the defined scope. If you want to expand the RFC 1918 address space, most networks can ignore the change unless they want to add support in their own administrative domain (unless you leak). If you want to change them into Global Unicast addresses then multiple, independent network operators need to agree to deploy new code in operational support systems as well as network elements.

I should note that redesignation for 1/8, 233/8, and 240/4 has been proposed before:

https://tools.ietf.org/html/draft-hain-1918bis-01
https://tools.ietf.org/html/draft-wilson-class-e-02

While those are not multicast address blocks, I think that the likely challenges are sufficiently similar to make it worth speaking with the authors of those drafts to understand why their proposals did not result in changes.

Kind regards,

Leo Vegoda

---

From: Dave Taht <[email-masked]>
Date: Thu, 19 Dec 2019 09:42:35 -0800

> > have scanned the source code of the world and come up empty here.

Thx everybody for your feedback.

> I think the amount of attention required would vary depending on the defined scope. If you want to expand the RFC 1918 address space, most networks can ignore the change unless they want to add sup…

All true. But regardless of ultimate designations of global unicast or
private rfc1918-like address spaces, it needs to be technically made
to work, and made routable. I do see a pretty big need for a larger
CGN space somewhere (and not that I get to pick anything!!!), I'd use
230/7 for that.

In addition to creating the patches and a testbed, I've given two
talks on this, the better one is marred by a clothing malfunction,
but: https://www.youtube.com/watch?v=92aNK3ftz6M

> https://tools.ietf.org/html/draft-wilson-class-e-02

The class-e work was successful. Only windows of the major OSes did
not enable 240/4 as a viable address range 10 years ago. Adding
support for various routing protocols has been straightforward. I
sometimes think fondly about a portion of the internet entirely free
of windows born viruses and worms rather than trying to encourage them
to add support.

Linux finished the 240/4 fix (it worked in the "ip" command, not in
the "ifconfig" command) last year at around this time, 0/8 went in 6
months ago. Up next is this discussion of multicast spaces (which I
hope to add some new text to the drafty draft)

Had not the need for more space not been met successfully by CGNs back
then perhaps it would have moved forward in the standards.

> While those are not multicast address blocks, I think that the likely challenges are sufficiently similar to make it worth speaking with the authors of those drafts to understand why their proposal…

We did, and cited their work in our still drafty draft, here:

I would love to collect more feedback and bug reports regarding that
before we finally gird ourselves up for the ietf gauntlet. As things
stand today, although I'd really like as much feedback as possible, I
do not see a problem (over a 10 year timespan) with turning
225/8-231/8 into unicast.

-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 19 Dec 2019 19:51:35 +0000

-----Original Message-----
From: MBONED <[email-masked]> On Behalf Of Dave Taht

I think this is a bad idea. It would be okay to turn those multicast blocks into private multicast blocks, like 239/8, but to make them unicast blocks is asking for trouble. And probing the Internet, and finding that they "aren’t used," won’t explain why.

The fact is, whether done legally or not, networks do use 224/8 and 230/8, and likely others in that range, for internal IP multicast use, today. People don’t seem to obsess about RFC 2365 and 5771 sufficiently, it seems.

So, if we think that reclaiming some of those address blocks is a good idea, then I'd say, only if the reclaimed blocks are also used for multicast!

Bert

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 19 Dec 2019 14:39:31 -0800

Well, 225/8-231/8 and 235/8-238/8 are unassigned/reserved, so there's 
nothing to reclaim since there is no valid use of it in the first place 
(ie, they are squatters).

That said, I suspect there are much bigger technical issues with 
reassigning chunks of Class D space into unicast (beyond the linux source 
code).  I'm not a hw guy, but I imagine there's a lot of silicon out there 
that will not forward 224/4 packets using the unicast forwarding path.

On Thu, 19 Dec 2019, Manfredi (US), Albert E wrote:

| -----Original Message-----
| From: MBONED <[email-masked]> On Behalf Of Dave Taht
| 
| > I would love to collect more feedback and bug reports regarding that
| before we finally gird ourselves up for the ietf gauntlet. As things
| stand today, although I'd really like as much feedback as possible, I
| do not see a problem (over a 10 year timespan) with turning
| 225/8-231/8 into unicast.
| 
| I think this is a bad idea. It would be okay to turn those multicast blocks into private multicast blocks, like 239/8, but to make them unicast blocks is asking for trouble. And probing the Internet, and finding that they "aren’t used," won’t explain why.
| 
| The fact is, whether done legally or not, networks do use 224/8 and 230/8, and likely others in that range, for internal IP multicast use, today. People don’t seem to obsess about RFC 2365 and 5771 sufficiently, it seems.
| 
| So, if we think that reclaiming some of those address blocks is a good idea, then I'd say, only if the reclaimed blocks are also used for multicast!
| 
| Bert
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!NEt6yMaO-gk!Quiqoi5iqGRDgw5LVKQ2dVAihZV00oXZGmXVouuQvFHJ0tn5-8fIH-H6UbVEt3Y$ 
|

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Fri, 20 Dec 2019 00:15:20 +0000

-----Original Message-----
From: Leonard Giuliano <[email-masked]> 

Granted. Also, by the way, 233/8 and 234/8, squatters *that I know of*.

However, they are harmless squatters, because they use multicast. If we start introducing unicast in those address blocks, when we know these squatters exist, that won’t be harmless anymore.

Was wondering the same thing, but not being a hardware guy myself, I figured someone more personally impacted would pipe up. Splitting up the 1110xxxx prefix into blocks of unicast and blocks of multicast, when now the leading four bits always indicate multicast, might upset some hardware processing.

Bert