Mailing List Archive

Class D addresses? was: Redploying most of 127/8 as unicast public
On 11/20/21 10:44 AM, Chris Adams wrote:

[]

There is just as big a block of addresses with class D addresses for
broadcast. Is broadcast really even a thing these days? I know tons of
work went into it, but it always seemed that brute force and ignorance
won out using unicast. Even if it has some niche uses, I seriously doubt
that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it
seems that class D and class E would be a much better target than loopback.

Mike, not that I have any stake in this
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On Sat, Nov 20, 2021 at 1:02 PM Michael Thomas <mike@mtcc.com> wrote:
> On 11/20/21 10:44 AM, Chris Adams wrote:

> that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it
> seems that class D and class E would be a much better target than loopback.
> Mike, not that I have any stake in this

400M addresses may be excessive, but not so much the Low-hanging fruit
you seemed to suggest. May be worth the consideration to reduce,
but need to see your draft standard first, about what exactly you propose to
reclaim from class D..

Unlike class E and 127/8, there are many protocols and applications that
communicate between separate devices on a network over class D in a
non-unicast manner to contend with that utilize either official MC assignments,
or Private/org-specific assignments from available class D space

- Multicast/broadcast addresses used by many control systems such as
routing protocols (VRRP),
camera systems / physical security, etc.

--
-JH
Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On 11/20/21 11:01, Michael Thomas wrote:

> There is just as big a block of addresses with class D addresses for
> broadcast. Is broadcast really even a thing these days? I know tons of
> work went into it, but it always seemed that brute force and ignorance
> won out using unicast. Even if it has some niche uses, I seriously doubt
> that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it
> seems that class D and class E would be a much better target than loopback.

It's multicast, not broadcast. A very small chunk is used by some
routing protocols and it has uses in several streaming applications, but
indeed it's much larger than it practically needs to be.

However, IMNSHO, all of these proposals if adopted are really just going
to make a few people richer in the short term after their adoption and
will not do anything significant to solve the problem of IPv4 exhaustion
long-term.

--
Jay Hennigan - jay@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On Sat, Nov 20, 2021 at 11:02 AM Michael Thomas <mike@mtcc.com> wrote:
> Even if it has some niche uses, I seriously doubt
> that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it
> seems that class D and class E would be a much better target than loopback.

Hi Mike,

If you follow the links there are multiple proposals split by the
address space they apply to. There's one for 240/4 and another for
224/4 in addition to the one we've been discussing for 127/8.

Obviously the one for 240/4 is the lowest hanging fruit of the bunch.

> There is just as big a block of addresses with class D addresses for
> broadcast. Is broadcast really even a thing these days?

Multicast is not the same as broadcast and yes, it's a thing. Mainly
it's a thing confined to the local broadcast domain but in that scope
it's quite widely used. A lot of routing protocols (including OSPF)
use multicast, for example. However, while it's widely used there
aren't very many -different- things using it so only a tiny fraction
of the 224/4 space has been assigned to anything in common use.

If I had to guess, changing 224/4 is probably the biggest lift. The
other proposals mainly involve altering configuration, removing some
possibly hardcoded filters and in a few cases waiting for silicon to
age out of the system. Changing 224/4 means following a different code
path which does something fundamentally different with the packets --
unicast instead of multicast.

Regards,
Bill Herrin



--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
It appears that Michael Thomas <mike@mtcc.com> said:
>There is just as big a block of addresses with class D addresses for
>broadcast. Is broadcast really even a thing these days?

It's multicast and no, but it hardly matters.

It's the same problem, if you wanted to turn it into unicast space you'd need
a global forklift upgrade.

FWIW, I see a trickle of class D traffic coming through my router but no class E.

R's,
John
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On 11/20/21 11:41 AM, Jay Hennigan wrote:
> On 11/20/21 11:01, Michael Thomas wrote:
>
>> There is just as big a block of addresses with class D addresses for
>> broadcast. Is broadcast really even a thing these days? I know tons
>> of work went into it, but it always seemed that brute force and
>> ignorance won out using unicast. Even if it has some niche uses, I
>> seriously doubt that it needs 400M addresses. If you wanted to
>> reclaim ipv4 addresses it seems that class D and class E would be a
>> much better target than loopback.
>
> It's multicast, not broadcast. A very small chunk is used by some
> routing protocols and it has uses in several streaming applications,
> but indeed it's much larger than it practically needs to be.
>
> However, IMNSHO, all of these proposals if adopted are really just
> going to make a few people richer in the short term after their
> adoption and will not do anything significant to solve the problem of
> IPv4 exhaustion long-term.
>
Yeah, sorry brain fart. I'm mostly in the camp of just getting on with
it with ipv6, but starving the beast doesn't have a great track record.
We are talking about 20% of the address space that's being wasted so
it's not nothing.

Mike
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On 11/20/21 11:51 AM, William Herrin wrote:
>
> If I had to guess, changing 224/4 is probably the biggest lift. The
> other proposals mainly involve altering configuration, removing some
> possibly hardcoded filters and in a few cases waiting for silicon to
> age out of the system. Changing 224/4 means following a different code
> path which does something fundamentally different with the packets --
> unicast instead of multicast.

Yes, I agree it's the hardest. But if you're going to make changes at
all you might as well get all of them. Was it the politics of ipv6 that
this didn't get resolved in the 90's when it was a lot more tractable?

Mike
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On Sat, Nov 20, 2021 at 12:03 PM Michael Thomas <mike@mtcc.com> wrote:
> Was it the politics of ipv6 that
> this didn't get resolved in the 90's when it was a lot more tractable?

No, in the '90s we didn't have nearly the basis for looking ahead. We
might still have invented a new way to use IP addresses that required
a block that wasn't unicast. It was politics in the 2000's and the
2010's, as it is today.

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On 11/20/21 12:37 PM, William Herrin wrote:
> On Sat, Nov 20, 2021 at 12:03 PM Michael Thomas <mike@mtcc.com> wrote:
>> Was it the politics of ipv6 that
>> this didn't get resolved in the 90's when it was a lot more tractable?
> No, in the '90s we didn't have nearly the basis for looking ahead. We
> might still have invented a new way to use IP addresses that required
> a block that wasn't unicast. It was politics in the 2000's and the
> 2010's, as it is today.

In the early to mid 90's it was still a crap shoot of whether IP was
going to win (though it was really the only game in town for non-lan)
but by when I started at Cisco in 1998 it was the clear winner with
broadband starting to roll out. It was also obvious that v4 address
space was going to run out which of course was the core reason for v6.
So I don't understand why this didn't get done then when it was a *lot*
easier. It sure smacks of politics.

Mike
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
Hi,

On Sat, Nov 20, 2021 at 11:01:35AM -0800, Michael Thomas wrote:
>
> On 11/20/21 10:44 AM, Chris Adams wrote:
>
> []
>
> won out using unicast. Even if it has some niche uses, I seriously doubt
> that it needs 400M addresses. If you wanted to reclaim ipv4 addresses it
> seems that class D and class E would be a much better target than loopback.

I agree from an efficiency (= ratio of resources used vs. result achieved), but this wouldn't work in practice outside isolated environments for the same reasons why the 127/8 is not going to work:
https://theinternetprotocolblog.wordpress.com/2019/10/06/some-notes-on-ipv4-address-space/

For the sake of the thread it should be noted that both the reception of and the response to the initial e-mail primarily happened over IPv6.

I wish everybody a great weekend

Enno






--
Enno Rey

Cell: +49 173 6745902
Twitter: @Enno_Insinuator
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
Subject: Re: Class D addresses? was: Redploying most of 127/8 as unicast public Date: Sat, Nov 20, 2021 at 11:51:24AM -0800 Quoting William Herrin (bill@herrin.us):

> Multicast is not the same as broadcast and yes, it's a thing. Mainly
> it's a thing confined to the local broadcast domain but in that scope
> it's quite widely used.

All the heavy lifting in video production via IP is done over
multicast. Mostly, it is internal to one organisation, and the 239/8
(RFC2365) block is being used, but routing multi-gbit RTP flows over
multicast is a thing where I work.

--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
YOU!! Give me the CUTEST, PINKEST, most charming little VICTORIAN
DOLLHOUSE you can find!! An make it SNAPPY!!
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On Sat, 20 Nov 2021 at 22:14, Måns Nilsson <mansaxel@besserwisser.org>
wrote:

> Subject: Re: Class D addresses? was: Redploying most of 127/8 as unicast
> public Date: Sat, Nov 20, 2021 at 11:51:24AM -0800 Quoting William Herrin (
> bill@herrin.us):
> All the heavy lifting in video production via IP is done over
> multicast. Mostly, it is internal to one organisation, and the 239/8
> (RFC2365) block is being used, but routing multi-gbit RTP flows over
> multicast is a thing where I work.
>

239/8 can essentially be looked at as RFC1918 space for multicast. Possibly
time to consider using SSM and the 232/8 block? I hear they have multicast
in IPv6 now. \s

Anyway, AFAICT the 224/4 proposal is actually the 225/8-231/8 proposal,
leaving 224/8 out from that block of otherwise 224/5 (as 232/8-239/8 are
not covered in the proposal).

M
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On Nov 20, 2021, at 3:50 PM, Michael Thomas <mike@mtcc.com> wrote:
>
> In the early to mid 90's it was still a crap shoot of whether IP was going to win (though it was really the only game in town for non-lan) but by when I started at Cisco in 1998 it was the clear winner with broadband starting to roll out. It was also obvious that v4 address space was going to run out which of course was the core reason for v6. So I don't understand why this didn't get done then when it was a *lot* easier. It sure smacks of politics.
>
> Mike

In the in the 90s and into early 21st century Hesitancy toward IPv6 was partly technical, partly political, but mostly, Middle Management Myopia™. The rallying cry was, “Not on my cost center until I have a contract.” Subsequently, $DAYJOB company would/could not demonstrate IPv6 capability.

My $DAYJOB company no longer exists.

How many other companies will cease to exist as the world passes by them?
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
Bill,


On 20.11.21 21:37, William Herrin wrote:
> On Sat, Nov 20, 2021 at 12:03 PM Michael Thomas <mike@mtcc.com> wrote:
>> Was it the politics of ipv6 that
>> this didn't get resolved in the 90's when it was a lot more tractable?
> No, in the '90s we didn't have nearly the basis for looking ahead. We
> might still have invented a new way to use IP addresses that required
> a block that wasn't unicast. It was politics in the 2000's and the
> 2010's, as it is today.

That really isn't what happened.

In 2008, Vince Fuller, Dave Meyer, and I put together
draft-fuller-240space, and we presented it to the IETF. There were
definitely people who thought we should just try to get to v6, but what
really stopped us was a point that Dave Thaler made: unintended impact
on non-participating devices, and in particular CPE/consumer firewall
gear, and at the time there were  serious concerns about some endpoint
systems as well.  Back then it might have been possible to use the space
as part of an SP interior, but no SP demonstrated any interest at the
time, because it would have amounted to an additional transition.

Eliot
RE: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
“In the early to mid 90's it was still a crap shoot of whether IP was
going to win (though it was really the only game in town for non-lan)
but by when I started at Cisco in 1998 it was the clear winner with
broadband starting to roll out”

</Lurk>

IP was the clear winner since the Clinton-Gore Initiative of 1991, as we called it in 1991. (History records this as the “Gore Bill”, feel free to Google.) [ He invented the Internet, you know! ???? ] at which time we began prototype conversion of non-DOD Government agencies to “The IP Paradigm”, till about 94-95, when the next phase was rollout to K-12 and Public libraries, as well as mainstream ISP’s. This necessitated the birth of the NAP’s. These NAP’s were supposed to be -Private- sector, not Public. Many of us “Riding the Bill” left Public sector contracting to Private sector to facilitate this transition. (Hence the date of my ARIN-POC, actually just POC, ARIN didn’t exist yet) The debate in 95 was not “IP or not IP”, it was “Will your NAP be FDDI like the MAE’s, ATM, or even the LINX model of a GIGE switch. (Frame was already fading) “ While in private sector there may have been some doubt, the IP Juggernaut was well underway in Government by almost half a decade, and as they say “That is the sound of inevitability, Neo”, at that point. IP was as “nailed to the wall” early to mid 90’s as Tony Li’s resignation was to his bosses door, at Cisco, a year or so, later. However, FWIW, the private sector had yet to hear the sound of the train. Many brand protocol loyalist fought IP adoption all the way until their favorite brand -adopted- it, so I understand your perspective.

FWIW, I miss being able to fit into my “No 53” Tee Shirt. ?

Matter of fact, many of us missed the foreshadowing of the “woke” generation when we got in trouble for painting cross hairs on a backhoe for a NANOG Tee… it got “banned” for “possibly inciting violence against backhoe operators” .

:-*

<Lurk>

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

From: Michael Thomas<mailto:mike@mtcc.com>
Sent: Saturday, November 20, 2021 3:52 PM
To: William Herrin<mailto:bill@herrin.us>
Cc: nanog@nanog.org<mailto:nanog@nanog.org>
Subject: Re: Class D addresses? was: Redploying most of 127/8 as unicast public


On 11/20/21 12:37 PM, William Herrin wrote:
> On Sat, Nov 20, 2021 at 12:03 PM Michael Thomas <mike@mtcc.com> wrote:
>> Was it the politics of ipv6 that
>> this didn't get resolved in the 90's when it was a lot more tractable?
> No, in the '90s we didn't have nearly the basis for looking ahead. We
> might still have invented a new way to use IP addresses that required
> a block that wasn't unicast. It was politics in the 2000's and the
> 2010's, as it is today.

In the early to mid 90's it was still a crap shoot of whether IP was
going to win (though it was really the only game in town for non-lan)
but by when I started at Cisco in 1998 it was the clear winner with
broadband starting to roll out. It was also obvious that v4 address
space was going to run out which of course was the core reason for v6.
So I don't understand why this didn't get done then when it was a *lot*
easier. It sure smacks of politics.

Mike
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On Sun, Nov 21, 2021 at 4:16 AM Eliot Lear <lear@ofcourseimright.com> wrote:
> In 2008, Vince Fuller, Dave Meyer, and I put together
> draft-fuller-240space, and we presented it to the IETF. There were
> definitely people who thought we should just try to get to v6, but what
> really stopped us was a point that Dave Thaler made: unintended impact
> on non-participating devices, and in particular CPE/consumer firewall
> gear, and at the time there were serious concerns about some endpoint
> systems as well. Back then it might have been possible to use the space
> as part of an SP interior, but no SP demonstrated any interest at the
> time, because it would have amounted to an additional transition.

Hi Eliot,

I wasn't in the working group so I'll take your word for it. Something
rather different happened later when folks on NANOG discovered that
the IETF had considered and abandoned the idea. Opinion coalesced into
two core groups:

Group 1: Shut up and use IPv6. We don't want the IETF or vendors
distracted from that effort with improvements to IPv4. Mumble mumble
titanic deck chairs harrumph.

Group 2: Why is the IETF being so myopic? We're likely to need more
IPv4 addresses, 240/4 is untouched, and this sort of change has a long
lead time. Mumble mumble heads up tailpipes harrumph.


More than a decade later, the "titantic" is shockingly still afloat
and it would be strikingly useful if there were a mostly working /4 of
IP addresses we could argue about how best to employ.

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 21, 2021, at 1:20 PM, William Herrin <bill@herrin.us> wrote:
>
> On Sun, Nov 21, 2021 at 4:16 AM Eliot Lear <lear at ofcourseimright.com> wrote:
>> In 2008, Vince Fuller, Dave Meyer, and I put together
>> draft-fuller-240space, and we presented it to the IETF. There were
>> definitely people who thought we should just try to get to v6, but what
>> really stopped us was a point that Dave Thaler made: unintended impact
>> on non-participating devices, and in particular CPE/consumer firewall
>> gear, and at the time there were serious concerns about some endpoint
>> systems as well. Back then it might have been possible to use the space
>> as part of an SP interior, but no SP demonstrated any interest at the
>> time, because it would have amounted to an additional transition.
>
> Hi Eliot,
>
> I wasn't in the working group so I'll take your word for it. Something
> rather different happened later when folks on NANOG discovered that
> the IETF had considered and abandoned the idea. Opinion coalesced into
> two core groups:
>
> Group 1: Shut up and use IPv6. We don't want the IETF or vendors
> distracted from that effort with improvements to IPv4. Mumble mumble
> titanic deck chairs harrumph.
>
> Group 2: Why is the IETF being so myopic? We're likely to need more
> IPv4 addresses, 240/4 is untouched, and this sort of change has a long
> lead time. Mumble mumble heads up tailpipes harrumph.
>
>
> More than a decade later, the "titantic" is shockingly still afloat
> and it would be strikingly useful if there were a mostly working /4 of
> IP addresses we could argue about how best to employ.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> bill at herrin.us
> https://bill.herrin.us/
>

I agree, generally speaking. IMO, it’s unfortunate that these addresses are being held in “limbo” while these debates go on. I’m not complaining about the debates per se, but the longer we go without resolution, these addresses can’t be put to any (documented) use.

There’s background information available that might be helpful to those who haven’t yet seen it:

https://datatracker.ietf.org/doc/slides-70-intarea-4/ <https://datatracker.ietf.org/doc/slides-70-intarea-4/> (links to the draft-fuller-240space slides from IETF 70)
https://datatracker.ietf.org/doc/minutes-70-intarea/ <https://datatracker.ietf.org/doc/minutes-70-intarea/> (IETF 70 INTAREA meeting minutes)
https://mailman.nanog.org/pipermail/nanog/2007-October/thread.html <https://mailman.nanog.org/pipermail/nanog/2007-October/thread.html> (NANOG October 2007 mail archives, containing links to the “240/4” thread)
https://puck.nether.net/pipermail/240-e/ <https://puck.nether.net/pipermail/240-e/> (the 240-e archives)
https://mailarchive.ietf.org/arch/browse/int-area/ <https://mailarchive.ietf.org/arch/browse/int-area/> (IETF INTAREA archives, containing comments on the 240space draft and related issues, roughly in the same time frame as in the previous links)

—gregbo
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
Greg

Thanks for posting the links.  Our old draft seems to have largely had
its intended effect without ever having been issued as an RFC
(moohaha).  Most implementations don't hardcode 240/4 into a bogon
filter.  We had at the time left open what next steps should be.

So what's the road to actually being able to use this space?  It
depends.  If you want to use it for your interior, and return
routability beyond your AS and external in-addr service is NOT
important, all that stops you today is whatever set of issues you find
in your own back yard.

If you want to allocate space to customers or need in-addr/return
routability, obviously that's More Work that should not be
underestimated.  240/4 appears in a number of bogon filters, not all of
which are controlled by people tracking operator lists or the IETF.

And that complicates matters in terms of whether the space should be
moved to a unallocated or treated like 10/8.  At least the latter seems
to match the testing that has thus far been performed.

Eliot


On 23.11.21 02:01, Greg Skinner via NANOG wrote:
>
>> On Nov 21, 2021, at 1:20 PM, William Herrin <bill@herrin.us> wrote:
>>
>> On Sun, Nov 21, 2021 at 4:16 AM Eliot Lear <lear at
>> ofcourseimright.com <http://ofcourseimright.com>> wrote:
>>> In 2008, Vince Fuller, Dave Meyer, and I put together
>>> draft-fuller-240space, and we presented it to the IETF. There were
>>> definitely people who thought we should just try to get to v6, but what
>>> really stopped us was a point that Dave Thaler made: unintended impact
>>> on non-participating devices, and in particular CPE/consumer firewall
>>> gear, and at the time there were  serious concerns about some endpoint
>>> systems as well.  Back then it might have been possible to use the space
>>> as part of an SP interior, but no SP demonstrated any interest at the
>>> time, because it would have amounted to an additional transition.
>>
>> Hi Eliot,
>>
>> I wasn't in the working group so I'll take your word for it. Something
>> rather different happened later when folks on NANOG discovered that
>> the IETF had considered and abandoned the idea. Opinion coalesced into
>> two core groups:
>>
>> Group 1: Shut up and use IPv6. We don't want the IETF or vendors
>> distracted from that effort with improvements to IPv4. Mumble mumble
>> titanic deck chairs harrumph.
>>
>> Group 2: Why is the IETF being so myopic? We're likely to need more
>> IPv4 addresses, 240/4 is untouched, and this sort of change has a long
>> lead time. Mumble mumble heads up tailpipes harrumph.
>>
>>
>> More than a decade later, the "titantic" is shockingly still afloat
>> and it would be strikingly useful if there were a mostly working /4 of
>> IP addresses we could argue about how best to employ.
>>
>> Regards,
>> Bill Herrin
>>
>>
>> --
>> William Herrin
>> bill at herrin.us <http://herrin.us>
>> https://bill.herrin.us/
>>
>
> I agree, generally speaking.  IMO, it’s unfortunate that these
> addresses are being held in “limbo” while these debates go on.  I’m
> not complaining about the debates per se, but the longer we go without
> resolution, these addresses can’t be put to any (documented) use.
>
> There’s background information available that might be helpful to
> those who haven’t yet seen it:
>
> https://datatracker.ietf.org/doc/slides-70-intarea-4/ (links to the
> draft-fuller-240space slides from IETF 70)
> https://datatracker.ietf.org/doc/minutes-70-intarea/ (IETF 70 INTAREA
> meeting minutes)
> https://mailman.nanog.org/pipermail/nanog/2007-October/thread.html (NANOG
> October 2007 mail archives, containing links to the “240/4” thread)
> https://puck.nether.net/pipermail/240-e/ (the 240-e archives)
> https://mailarchive.ietf.org/arch/browse/int-area/ (IETF INTAREA
> archives, containing comments on the 240space draft and related
> issues, roughly in the same time frame as in the previous links)
>
> —gregbo
>
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On Tue, Nov 23, 2021 at 5:03 AM Eliot Lear <lear@ofcourseimright.com> wrote:
> So what's the road to actually being able to use [240/4]?

1. Move it from "reserved" to "unallocated unicast" (IETF action)
2. Wait 10 years
3. Now that nearly all equipment that didn't treat it as
yet-to-be-allocated unicast has cycled out of use, argue about what to
allocate the addresses to for best effect.


Similar plan for 0/8, 255/8 and 127/8-127.0/16:

1. Move from their existing status to "deprecated former use;
unallocated unicast."
2. Wait 10 years.
3. Now that most equipment that didn't treat it as yet-to-be-allocated
unicast has cycled out of use, argue about what to allocate the
addresses to.


Bottom line though is that the IETF has to act before anyone else
reasonably can.

Regards,
Bill Herrin

--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On Nov 23, 2021, at 10:33 AM, William Herrin <bill@herrin.us> wrote:
> ?On Tue, Nov 23, 2021 at 5:03 AM Eliot Lear <lear@ofcourseimright.com> wrote:
>> So what's the road to actually being able to use [240/4]?
>
> 1. Move it from "reserved" to "unallocated unicast" (IETF action)
> 2. Wait 10 years
> 3. Now that nearly all equipment that didn't treat it as
> yet-to-be-allocated unicast has cycled out of use, argue about what to
> allocate the addresses to for best effect.

Or…

1. IAB or IESG requests the IANA team to delegate one of the 240/4 /8s to the RIRs on demand for experimental purposes for a fixed period of time (a year or two?).
2. The RIRs, with input from their communities, formulate research programs to explore the viability of the space they have just received for “normal” unicast space.
3. The RIRs assign that space in accordance with those research programs.
4. At the end of the fixed period of time, research reports are published.
5. Armed with hard data on the usability of the 240/4 /8s allocated, people can scream past each other much more authoritatively on the topic of what to do with 240/4.

> Bottom line though is that the IETF has to act before anyone else
> reasonably can.


To be honest, I don’t think it actually matters if it is the IAB, the IESG, or the NRO that directs the IANA to do stuff (although Kim @ IANA might have a different opinion and he’s more authoritative). What I believe matters is that there is consensus that additional data is needed. I’m not sure we’re at that point as yet — too many people appear to know The Truth.

Regards,
-drc
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On Tue, Nov 23, 2021 at 9:02 PM David Conrad <drc@virtualized.org> wrote:
> On Nov 23, 2021, at 10:33 AM, William Herrin <bill@herrin.us> wrote:
> > 1. Move it from "reserved" to "unallocated unicast" (IETF action)
>
> Or…
>
> 1. IAB or IESG requests the IANA team to delegate one of
> the 240/4 /8s to the RIRs on demand for experimental
> purposes for a fixed period of time (a year or two?).

Hi David,

I like research but what would the RIRs study? The percentage of the
2021 Internet reachable from a station assigned a 240/4 IP address?
Suppose it's 95%? Or 50%? Is there a difference? Neither one is enough
to deploy the addresses for 2021 global use.

> 5. Armed with hard data on the usability of the 240/4 /8s
> allocated, people can scream past each other much more
> authoritatively on the topic of what to do with 240/4.

Which is not particularly valuable. We already know the addresses are
dysfunctional on the 2021 Internet. There's no credible disagreement
on that point. We don't particularly need to know it more
authoritatively. What we need to know more authoritatively is: IF we
tell vendors and operators to expect those addresses to come into use
and alter their equipment and configurations accordingly, -how long-
will it be until the addresses are usable on the Internet. 2026? 2031?
2051? That research could be valuable, but it can't usefully start
until:

> 1. Move 240/4 from "reserved" to "unallocated unicast"

So maybe instead of

> 2. Wait 10 years

It's

> 2. IAB or IESG requests the IANA team to delegate one of
> the 240/4 /8s to the RIRs on demand for experimental
> purposes for a fixed period of time

But that still starts with:

> 1. Move 240/4 from "reserved" to "unallocated unicast"

Regards,
Bill Herrin

--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
Bill,

On Nov 23, 2021, at 11:12 PM, William Herrin <bill@herrin.us> wrote:
>> 1. IAB or IESG requests the IANA team to delegate one of
>> the 240/4 /8s to the RIRs on demand for experimental
>> purposes for a fixed period of time (a year or two?).
>
> I like research but what would the RIRs study? The percentage of the
> 2021 Internet reachable from a station assigned a 240/4 IP address?
> Suppose it's 95%? Or 50%? Is there a difference? Neither one is enough
> to deploy the addresses for 2021 global use.

Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC and they said similar things when 1.1.1.0/24 was stood up as an experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.

>> 5. Armed with hard data on the usability of the 240/4 /8s
>> allocated, people can scream past each other much more
>> authoritatively on the topic of what to do with 240/4.
>
> Which is not particularly valuable. We already know the addresses are
> dysfunctional on the 2021 Internet. There's no credible disagreement
> on that point.

Seems to me that a number of folks on this list and during this discussion would disagree with a blanket assertion that 240/4 is “dysfunctional on the 2021 Internet” - some of them even wrote a draft discussing the possibility.

>> 2. IAB or IESG requests the IANA team to delegate one of
>> the 240/4 /8s to the RIRs on demand for experimental
>> purposes for a fixed period of time
>
> But that still starts with:
>
>> 1. Move 240/4 from "reserved" to "unallocated unicast"

OK, but this seems like a quibble. The status for 240/4 is “ RESERVED: designated by the IETF for specific non-global-unicast purposes as noted.” The “as noted” part is “Future Use”. As far as I’m aware, “future use” would not preclude “experimental use” however if it makes people feel better to have an IANA considerations section that says the prefixes need to be moved to ALLOCATED, I struggle to see how that would be a problem.

Regards,
-drc
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
On Wed, Nov 24, 2021 at 4:36 PM David Conrad <drc@virtualized.org> wrote:
>> I like research but what would the RIRs study? The percentage of the
>
> Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC
> and they said similar things when 1.1.1.0/24 was stood up as an
> experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.

Hi David,

I don't recall there being any equipment or software compatibility
concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. As
I recall it, there were concerns with prior local use and potential
trash traffic. It seemed likely those concerns could be addressed with
experiments, and the experiments in fact addressed them.

The prior local use worry reared its head again with 240/4 but given
the prior experience with 1.0.0.0/8 I don't personally believe we need
to re-run that experiment just because the numbers are part of a
different block.


> Seems to me that a number of folks on this list and during this
> discussion would disagree with a blanket assertion that 240/4
> is “dysfunctional on the 2021 Internet” - some of them even
> wrote a draft discussing the possibility.

Line them up. Show of hands. Who really thinks that if we assign
240.0.0.1 to a customer tomorrow without waiting for anyone to clean
up their software and hardware, you won't get enough complaints about
things not working that you have to take it back and assign a
different address instead?


> 1. Move 240/4 from "reserved" to "unallocated unicast"
>
> OK, but this seems like a quibble. The status for 240/4 is “
> RESERVED: designated by the IETF for specific non-global-unicast
> purposes as noted.” The “as noted” part is “Future Use”.

It's not a quibble. Some vendors take the current status to mean
"treat it like unicast until we're told otherwise." Others take the
status to mean, "packets with these addresses are bogons without a
defined routing behavior until we're told otherwise." The result is
incompatible behavior between vendors. Changing that direction to
"treat it like unicast" without ambiguity is not a quibble.

Regards,
Bill Herrin

--
William Herrin
bill@herrin.us
https://bill.herrin.us/
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
Le Wed, Nov 24, 2021 at 05:08:43PM -0800, William Herrin a ?crit :
> I don't recall there being any equipment or software compatibility
> concerns with 1.0.0.0/8. If you do, feel free to refresh my memory.

Perhaps not the whole /8 but definitely some buggy implementations :
https://seclists.org/nanog/2018/Apr/52
Re: Class D addresses? was: Redploying most of 127/8 as unicast public [ In reply to ]
> On Nov 24, 2021, at 5:08 PM, William Herrin <bill@herrin.us> wrote:
>
> On Wed, Nov 24, 2021 at 4:36 PM David Conrad <drc@virtualized.org> wrote:
>>> I like research but what would the RIRs study? The percentage of the
>>
>> Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC
>> and they said similar things when 1.1.1.0/24 was stood up as an
>> experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.
>
> Hi David,
>
> I don't recall there being any equipment or software compatibility
> concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. As
> I recall it, there were concerns with prior local use and potential
> trash traffic. It seemed likely those concerns could be addressed with
> experiments, and the experiments in fact addressed them.
>
> The prior local use worry reared its head again with 240/4 but given
> the prior experience with 1.0.0.0/8 I don't personally believe we need
> to re-run that experiment just because the numbers are part of a
> different block.
>
>
>> Seems to me that a number of folks on this list and during this
>> discussion would disagree with a blanket assertion that 240/4
>> is “dysfunctional on the 2021 Internet” - some of them even
>> wrote a draft discussing the possibility.
>
> Line them up. Show of hands. Who really thinks that if we assign
> 240.0.0.1 to a customer tomorrow without waiting for anyone to clean
> up their software and hardware, you won't get enough complaints about
> things not working that you have to take it back and assign a
> different address instead?
>
>
>> 1. Move 240/4 from "reserved" to "unallocated unicast"
>>
>> OK, but this seems like a quibble. The status for 240/4 is “
>> RESERVED: designated by the IETF for specific non-global-unicast
>> purposes as noted.” The “as noted” part is “Future Use”.
>
> It's not a quibble. Some vendors take the current status to mean
> "treat it like unicast until we're told otherwise." Others take the
> status to mean, "packets with these addresses are bogons without a
> defined routing behavior until we're told otherwise." The result is
> incompatible behavior between vendors. Changing that direction to
> "treat it like unicast" without ambiguity is not a quibble.
>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> bill@herrin.us
> https://bill.herrin.us/

For what it’s worth, I’ve been tracking this issue on other netops mailing lists. There is a recent post on the LACNOG list from Leandro Bertholdo <https://mail.lacnic.net/pipermail/lacnog/2021-November/008895.html> referencing https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/ <https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/>, a draft proposing another way to make additional IPv4 address space available. I haven’t had time to read the draft closely, but I noticed that it involves the use of 240/4. Subsequent googling about the draft turned up a presentation <https://www.avinta.com/phoenix-1/home/RegionalAreaNetworkArchitecture.pdf> describing how the techniques described could be deployed. I noticed that the presentation made reference to OpenWRT, so perhaps the authors are aware of the work that the authors of the IPv4 Unicast Extensions Project have done in that area.

The adaptive-ipv4 draft will expire sometime next month, so anyone interested in seeing it move forward should contact the authors.

—gregbo

1 2  View All