Re: Feasibility of using Class E space for public unicast (was re: 44/8)

[Stephen Satchell]

On 7/27/19 2:18 PM, Randy Bush wrote:
> something is broken on the nanog list.  usually we have this discussion
> twice a year.  this time it may have been a couple of years gap.  what
> broke?


44/8.  Sucked up all the oxygen.

Re: Feasibility of using Class E space for public unicast (was re: 44/8)

[Randy Bush]

something is broken on the nanog list.  usually we have this discussion
twice a year.  this time it may have been a couple of years gap.  what
broke?

randy

Re: Feasibility of using Class E space for public unicast (was re: 44/8)

[johnl]

In article <23868.39953.398906.559...@gargle.gargle.howl> you write:
>Not particularly interested in arguing for using Class E space but
>this "not compatible" reasoning would seem to have applied to IPv6 in
>the early 2000s (whatever, pick an earlier date when little supported
>IPv6) just as well, pretty much.

Right.  A point that's been made about a hundred times already is that the 
effort
to add class E to the IPv4 space is the same as the effort to support IPv6, so
why waste time with class E?

R's,
John

Feasibility of using Class E space for public unicast (was re: 44/8)

[bzs]

On July 26, 2019 at 21:19 do...@dougbarton.us (Doug Barton) wrote:
 > All of this, plus what Fred Baker said upthread.
 > 
 > When I was running the IANA in the early 2000's we discussed this issue with
 > many different experts, hardware company reps, etc. Not only was there a
 > software issue that was insurmountable for all practical purposes (pretty 
 > much
 > every TCP/IP stack has "Class E space is not unicast" built in), in the case 
 > of
 > basically all network hardware, this limitation is also in the silicon. So 
 > even
 > if it were possible to fix the software issue, it would not be possible to 
 > fix
 > the hardware issue without replacing pretty much all the hardware.
 > 

Not particularly interested in arguing for using Class E space but
this "not compatible" reasoning would seem to have applied to IPv6 in
the early 2000s (whatever, pick an earlier date when little supported
IPv6) just as well, pretty much.

So in and of itself it's not a show-stopper. Just a matter of whether
there's an overall positive ROI.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: Feasibility of using Class E space for public unicast (was re: 44/8)

[Doug Barton]

On 2019-07-26 11:01 PM, William Herrin wrote:

On Fri, Jul 26, 2019 at 10:36 PM Doug Barton > wrote:
> So I'll just say this ... if you think that the advice I received 
from all of the many people I spoke to (all of whom are/were a lot 
smarter than me on this topic) was wrong, and that putting the same 
LOE into IPv6 adoption that it would have taken to make Class E usable 
was a better investment


Doug,

"Better investment?" What on earth makes you think it's a zero-sum game?


Because for all of us there are only 24 hours in a day, and the people 
who would have needed to do the work to make it happen were telling me 
that they were going to put the work into IPv6 instead, because it has a 
future. As Owen pointed out, no matter how much IPv4 space you added, 
all it would do would be delay the inevitable.


"Same level of effort?" A reasonable level of effort was adding the 
word "unicast" to the word "reserved" in the standards. Seven letters. 
A space. Maybe a comma.

I don't recall seeing your draft on that  refresh my memory?
That would have unblocked everybody else to apply however much or 
little effort they cared to. Here we are nearly 20 years later and had 
you not fumbled that ball 240/4 might be broadly enough supported to 
usefully replace the word "reserved" with something else.
You give me /way /too much credit on that. I was the reed tasting the 
wind on this topic. I was not the wind. I (like every other IANA 
manager) had exactly zero authority to say, "You SHALL NOT pursue making 
Class E space usable for anything!" The opportunity existed then, and 
still exists today, for anyone to make it work.
You're right about one thing: you won't be able to convince me that 
your conclusion was rational. No matter how many smart people say a 
stupid thing, it's still a stupid thing.


So as my last word on the topic, I return you to the point above, that 
whatever the discussion was 20 years ago, there is still no workable 
solution.


If you'd like another perspective, here is a reasonably good summary:

https://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/

Doug

Re: Feasibility of using Class E space for public unicast (was re: 44/8)

[William Herrin]

On Fri, Jul 26, 2019 at 10:36 PM Doug Barton  wrote:
> So I'll just say this ... if you think that the advice I received from
all of the many people I spoke to (all of whom are/were a lot smarter than
me on this topic) was wrong, and that putting the same LOE into IPv6
adoption that it would have taken to make Class E usable was a better
investment

Doug,

"Better investment?" What on earth makes you think it's a zero-sum game?

"Same level of effort?" A reasonable level of effort was adding the word
"unicast" to the word "reserved" in the standards. Seven letters. A space.
Maybe a comma. That would have unblocked everybody else to apply however
much or little effort they cared to. Here we are nearly 20 years later and
had you not fumbled that ball 240/4 might be broadly enough supported to
usefully replace the word "reserved" with something else.

You're right about one thing: you won't be able to convince me that your
conclusion was rational. No matter how many smart people say a stupid
thing, it's still a stupid thing.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Feasibility of using Class E space for public unicast (was re: 44/8)

[Doug Barton]

On 2019-07-26 10:07 PM, William Herrin wrote:
On Fri, Jul 26, 2019 at 9:21 PM Doug Barton > wrote:
> When I was running the IANA in the early 2000's we discussed this 
issue with many different experts, hardware company reps, etc. Not 
only was there a software issue that was insurmountable for all 
practical purposes (pretty much every TCP/IP stack has "Class E space 
is not unicast" built in), in the case of basically all network 
hardware, this limitation is also in the silicon. So even if it were 
possible to fix the software issue, it would not be possible to fix 
the hardware issue without replacing pretty much all the hardware.


> So the decision was made to start tooting the IPv4 runout horns in 
the hopes that folks would start taking conservation of the space 
seriously (which happened more often than not), and accelerate the 
adoption of IPv6. *cough*


Hi Doug,

That's what you wrote. Here's what I read:

"We decided keep this mile of road closed because you can't drive it 
anywhere unless the toll road operators in the next 10 miles open 
their roads too. What's that you say? Your house is a quarter mile 
down this road?** La la la I can't hear you. Look, just use the shiny 
new road we built over in the next state instead. Move your house 
there. The roads are better."


** Not every unicast use of 240/4 would require broad adoption of the 
change. Your reasoning that it does is so absurd as to merit outright 
mockery.


> So no, there were exactly zero "IPv6 loons" involved in this 
decision. :-)


No, when I said IPv6 loonies, reasoning of this character was pretty 
much what I was talking about.


So leaving aside how interesting I find the fact that you snipped the 
part of my comments that you did, the utter absurdity of your toll road 
analogy shows me that I will not be able to convince you of anything.


So I'll just say this ... if you think that the advice I received from 
all of the many people I spoke to (all of whom are/were a lot smarter 
than me on this topic) was wrong, and that putting the same LOE into 
IPv6 adoption that it would have taken to make Class E usable was a 
better investment because we're not running out of IPv6 any time soon, 
then you have a golden opportunity. Go forth and prove me wrong. Go 
rally support from all of the people and companies that you need in 
order to make any part of  Class E usable for any purpose (even, as you 
point it, if it's not for global unicast). If you're right, and I'm 
wrong, your income potential is essentially limitless.


Or, look at it from another perspective. If you're right, then why, in 
the last almost 15 years, has no one figured out how to do it yet? 
Including the companies whose mission is to sell us new hardware, and 
force us into contracts for software upgrades in order to keep said 
hardware on the 'net?


It's easy to sit back in the cheap seats and squawk about how "they" are 
out to get you. I'd be far more impressed if you put your money (or 
time, or effort) where your mouth is.


Doug

Re: Feasibility of using Class E space for public unicast (was re: 44/8)

[William Herrin]

On Fri, Jul 26, 2019 at 9:21 PM Doug Barton  wrote:
> When I was running the IANA in the early 2000's we discussed this issue
with many different experts, hardware company reps, etc. Not only was there
a software issue that was insurmountable for all practical purposes (pretty
much every TCP/IP stack has "Class E space is not unicast" built in), in
the case of basically all network hardware, this limitation is also in the
silicon. So even if it were possible to fix the software issue, it would
not be possible to fix the hardware issue without replacing pretty much all
the hardware.

> So the decision was made to start tooting the IPv4 runout horns in the
hopes that folks would start taking conservation of the space seriously
(which happened more often than not), and accelerate the adoption of IPv6.
*cough*

Hi Doug,

That's what you wrote. Here's what I read:

"We decided keep this mile of road closed because you can't drive it
anywhere unless the toll road operators in the next 10 miles open their
roads too. What's that you say? Your house is a quarter mile down this
road?** La la la I can't hear you. Look, just use the shiny new road we
built over in the next state instead. Move your house there. The roads are
better."

** Not every unicast use of 240/4 would require broad adoption of the
change. Your reasoning that it does is so absurd as to merit outright
mockery.

> So no, there were exactly zero "IPv6 loons" involved in this decision.
:-)

No, when I said IPv6 loonies, reasoning of this character was pretty much
what I was talking about.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Feasibility of using Class E space for public unicast (was re: 44/8)

[Doug Barton]

On 2019-07-22 6:09 PM, Owen DeLong wrote:

On Jul 22, 2019, at 12:15 , Naslund, Steve > wrote:


I think the Class E block has been covered before.  There were two 
reasons to not re-allocate it.
1.A lot of existing code base does not know how to handle those 
addresses and may refuse to route them or will otherwise mishandle them.
2.It was decided that squeezing every bit of space out of the v4 
allocations only served to delay the desired v6 deployment.



Close, but there is a subtle error…

2.It was decided that the effort to modify each and every IP stack in 
order to facilitate use of this relatively small block (16 /8s being 
evaluated against a global
run rate at the time of roughly 2.5 /8s per month, mostly to RIPE and 
APNIC) vs. putting that same effort into modifying each and every IP 
stack to support
IPv6 was an equation of very small benefit for slightly smaller cost. 
(Less than 8 additional months of IPv4 free pool vs. hopefully making 
IPv6 deployable

before IPv4 ran out).


All of this, plus what Fred Baker said upthread.

When I was running the IANA in the early 2000's we discussed this issue 
with many different experts, hardware company reps, etc. Not only was 
there a software issue that was insurmountable for all practical 
purposes (pretty much every TCP/IP stack has "Class E space is not 
unicast" built in), in the case of basically all network hardware, this 
limitation is also in the silicon. So even if it were possible to fix 
the software issue, it would not be possible to fix the hardware issue 
without replacing pretty much all the hardware.


... and even if some magical forces appeared and gave every open source 
software project, and every company, and every consumer in the developed 
world the means and opportunity to do all of the above; doing so would 
have left the developing world out in the cold, since in many cases 
there is reliance on older, second/third/fourth hand equipment that they 
could never afford to replace.


So the decision was made to start tooting the IPv4 runout horns in the 
hopes that folks would start taking conservation of the space seriously 
(which happened more often than not), and accelerate the adoption of 
IPv6. *cough*


Personally, I also pushed to bring IPv6 support from ICANN up to par, 
including going the last mile on putting the IPv6 addresses of the root 
servers in the zone, creating and socializing a long-term plan for 
allocating to the RIRs, etc.


So no, there were exactly zero "IPv6 loons" involved in this decision. :-)

Doug