Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Dave Taht]

On Thu, Nov 25, 2021 at 8:25 AM Jared Mauch  wrote:
>
> On Fri, Nov 19, 2021 at 09:43:26AM -0800, Michael Thomas wrote:
> >
> > On 11/19/21 8:27 AM, Randy Bush wrote:
> > > these measurements would be great if there could be a full research-
> > > style paper, with methodology artifacts, and reproducible results.
> > > otherwise it disappears in the gossip stream of mailimg lists.
> > >
> > Maybe an experimental rfc making it a rfc 1918-like subnet and implementing
> > it on openwrt or something like that to see what happens. how many ip
> > cameras and the like roll over and die? same for class E addresses too, I
> > suppose. The question with anything that asks about legacy is how long the
> > long tail actually is.
> >
> > Mike, not that have any position on whether this is a good idea or not
>
> I can tell you it's observable out there and if i use my home network
> to follow default i can tell it is working through those devices at
> least.
>
> I agree with Randy it would be good if someone did this, it shouldn't be
> too hard with ripe atlas and a provider deciding to announce something

the atlas is good stuff, I am curious (OT) if they have added a
videoconferencing-like test to it?

> like 240.2.3.0/24 to see if it can be reached.

I very much would like a study of 240/4. In particular, announcing
255.255/16 might pick up a lot
of misconfigured routers out there.

Tests of the DNS would also be useful. This test setup has been
working for years now...

$ host postel.taht.net
postel.taht.net has address 85.90.246.167
postel.taht.net has address 255.255.255.254 # wireguard vpn presently
postel.taht.net has address 0.0.0.1 # wireguard vpn
postel.taht.net has IPv6 address 2a01:7e01:e001:28:f3ee:d002:0:beef #
ironically the ipv6 address is down and I hadn't noticed!

>
> That's at least a decent measurement and report, but the client
> side OS will still be a variable that is difficult to digest.  Not sure
> how many people are running very old IP stacks.  This is another hard to
> measure problem.
>
> - Jared
>
> --
> Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
> clue++;  | http://puck.nether.net/~jared/  My statements are only mine.



-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Jared Mauch]

On Fri, Nov 19, 2021 at 09:43:26AM -0800, Michael Thomas wrote:
> 
> On 11/19/21 8:27 AM, Randy Bush wrote:
> > these measurements would be great if there could be a full research-
> > style paper, with methodology artifacts, and reproducible results.
> > otherwise it disappears in the gossip stream of mailimg lists.
> > 
> Maybe an experimental rfc making it a rfc 1918-like subnet and implementing
> it on openwrt or something like that to see what happens. how many ip
> cameras and the like roll over and die? same for class E addresses too, I
> suppose. The question with anything that asks about legacy is how long the
> long tail actually is.
> 
> Mike, not that have any position on whether this is a good idea or not

I can tell you it's observable out there and if i use my home network
to follow default i can tell it is working through those devices at
least.

I agree with Randy it would be good if someone did this, it shouldn't be
too hard with ripe atlas and a provider deciding to announce something
like 240.2.3.0/24 to see if it can be reached.

That's at least a decent measurement and report, but the client
side OS will still be a variable that is difficult to digest.  Not sure
how many people are running very old IP stacks.  This is another hard to
measure problem.

- Jared

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Lincoln Dale]

On Thu, Nov 18, 2021 at 1:21 PM John Gilmore  wrote:

> We have found no ASIC IP implementations that
> hardwire in assumptions about specific IP address ranges.  If you know
> of any, please let us know, otherwise, let's let that strawman rest.
>

There's at least one. Marvell PresteriaCX (its either PresteriaCX or DX,
forget which). It is in Juniper EX4500, among others.
Hardware-based bogon filter when L3 routing that cannot be disabled.


cheers,

lincoln.

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[bzs]

On November 20, 2021 at 21:29 j...@west.net (Jay Hennigan) wrote:
 > > That depends on your timeline. Do you know many non-technical people
 > > still using their Pentium III computers with circa 2001 software
 > > versions? Connected to the Internet?

# date; lscpu

Sun Nov 21 20:14:44 EST 2021
Architecture:  i686
CPU op-mode(s):32-bit
Byte Order:Little Endian
CPU(s):2
On-line CPU(s) list:   0,1
Thread(s) per core:1
Core(s) per socket:1
Socket(s): 2
Vendor ID: GenuineIntel
CPU family:6
Model: 8
Model name:Pentium III (Coppermine)
Stepping:  3
CPU MHz:   933.075
BogoMIPS:  1866.25

(Ok it runs a somewhat newer opensuse.)

-- 
-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: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Michael Thomas]

On 11/20/21 9:29 PM, Jay Hennigan wrote:

On 11/19/21 10:27, William Herrin wrote:

Howdy,

That depends on your timeline. Do you know many non-technical people
still using their Pentium III computers with circa 2001 software
versions? Connected to the Internet?


There are lots of very old networked industrial machines with embedded 
computers operated by non-network-savvy people that are still very 
much in use.


Think CNC machines in machine shops, SCADA systems, etc. I wouldn't be 
a bit surprised to find quite a few 2001-era boxes still in service.


At some level I think there's a good chance that they'd just work. I 
wrote a significant amount of the Lantronix terminal server code and it 
never occurred to me that I should enforce rules about 127.0.0.0 or 
Class D or Class E. It really didn't have much bearing on a terminal 
server or the other host-like things we built. If you typed it in, it 
would work, if you  listened on a port it wouldn't care what the address 
was. I would imagine that lots of stacks from back in the day were just 
like that.


Mike

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[J. Hellenthal via NANOG]

Just replying to Joe's post here to add a little more context to at least one 
of the problems that will certainly appear if this would come about.

FreeBSD operators have been using this space for quite a long time for many 
NAT'ing reasons including firewalls and other services behind them for jail 
routing and such.

https://dan.langille.org/2013/12/29/freebsd-jails-on-non-routable-ip-addresses/

That's just one example that I've seen repeated in multiple other ways. One of 
which a jail operator with about 250 addresses out of that range that enabled 
his jail routed services.

Of course that can be changed but really for just this small of a influx of 
addresses ? Seems really wasteful to me.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Nov 20, 2021, at 23:54, Joe Maimon  wrote:
> 
> 
> Jay Hennigan wrote:
>>> On 11/19/21 10:27, William Herrin wrote:
>>> Howdy,
>>> That depends on your timeline. Do you know many non-technical people
>>> still using their Pentium III computers with circa 2001 software
>>> versions? Connected to the Internet?
>> 
>> There are lots of very old networked industrial machines with embedded 
>> computers operated by non-network-savvy people that are still very much in 
>> use.
>> 
>> Think CNC machines in machine shops, SCADA systems, etc. I wouldn't be a bit 
>> surprised to find quite a few 2001-era boxes still in service.
> In the context of re-purposed IPv4 address scopes specialized equipment will 
> tend to be fairly limited in its communication needs and unlikely to be 
> affected.
> 
> I certainly hope they are, otherwise the security implications are severe.
> 
> How about we recast this as general purpose internet communicating platforms 
> likely to have occasion to interact with these re-purposed addresses are 
> nearly certain to undergo an upgrade or more over the next decade, or how 
> many non-technical people are still using the original wrtg platform to 
> connect them to the internet?
> 
> And yes, its quite possible that even then those addresses may have some more 
> baggage than the typical IPv4 block in use today (which are hardly clean 
> bills of health more often than not).
> 
> But the sooner the effort begins the more likely the utilitarian value will 
> be there if or when its needed.
> 
> Joe

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Matthew Petach]

On Sat, Nov 20, 2021 at 6:27 PM Joe Maimon  wrote:

> Tom Beecher wrote:
> [...]
> >
> > IPv6 isn't perfect. That's not an excuse to ignore it and invest the
> > limited resources we have into Yet Another IPv4 Zombification Effort.
> >
> As noted earlier, False Dilemma
>
> Even worse, your thinking presupposes a finite amount of people-effort
> resources that must be properly managed by those superior in some
> fashion with more correct thinking.
>

This is absolutely true in the corporate world.

You have a finite number of people working a finite
number of hours each week on tasks that must be
prioritized based on business needs.

You can't magically make more people appear out
of thin air without spending more money, which is
generally against the needs of the business, and
you can't generally make more working hours appear
in the week without either magic or violating workers
rights.

Thus, you have a finite amount of people-effort resources
which must be managed by those higher up in the corporate
structure.

As an old boss of mine once said... "You sum it up so well."

Matt

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Eliot Lear]

Greetings John and all

On 18.11.21 21:54, John Gilmore wrote:

We succeeded in upgrading every end-node and every router in the
Internet in the late '90s and early 2000's, when we deployed CIDR.  It
was doable.  We know that because we did it!  (And if we hadn't done it,
the Internet would not have scaled to world scale.)


I want to highlight one (hopefully) entertaining point.  There is 
evidence in Geoff's and Tony's graphs of when all of this happened 
because there was a drop in the number of routes in 1994.  If you 
squint, you can see it here  just at the lower 
left-hand side of the graph.  It's really funny to me because the scale 
of that graph has changed *dramatically* – bordering on two orders of 
magnitude.  At the time the dip was a substantial percentage of the 
routes at the time.


I will also point out that even though endpoints by-and-large were not 
involved, keeping the routers from falling down nevertheless was the 
result of an enormous effort and collaboration between researchers, 
developers, and operators, who I doubt very much would ever want to 
repeat that sort of experience.


Eliot




OpenPGP_0x87B66B46D9D27A33_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Joe Maimon]

Jay Hennigan wrote:

On 11/19/21 10:27, William Herrin wrote:

Howdy,

That depends on your timeline. Do you know many non-technical people
still using their Pentium III computers with circa 2001 software
versions? Connected to the Internet?


There are lots of very old networked industrial machines with embedded 
computers operated by non-network-savvy people that are still very 
much in use.


Think CNC machines in machine shops, SCADA systems, etc. I wouldn't be 
a bit surprised to find quite a few 2001-era boxes still in service.


In the context of re-purposed IPv4 address scopes specialized equipment 
will tend to be fairly limited in its communication needs and unlikely 
to be affected.


I certainly hope they are, otherwise the security implications are severe.

How about we recast this as general purpose internet communicating 
platforms likely to have occasion to interact with these re-purposed 
addresses are nearly certain to undergo an upgrade or more over the next 
decade, or how many non-technical people are still using the original 
wrtg platform to connect them to the internet?


And yes, its quite possible that even then those addresses may have some 
more baggage than the typical IPv4 block in use today (which are hardly 
clean bills of health more often than not).


But the sooner the effort begins the more likely the utilitarian value 
will be there if or when its needed.


Joe

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Jay Hennigan]

On 11/19/21 10:27, William Herrin wrote:

Howdy,

That depends on your timeline. Do you know many non-technical people
still using their Pentium III computers with circa 2001 software
versions? Connected to the Internet?


There are lots of very old networked industrial machines with embedded 
computers operated by non-network-savvy people that are still very much 
in use.


Think CNC machines in machine shops, SCADA systems, etc. I wouldn't be a 
bit surprised to find quite a few 2001-era boxes still in service.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Joe Maimon]

Tom Beecher wrote:



The biggest impediment to IPv6 adoption is that too many people invest 
too much time and resources in finding ways to squeeze more blood from 
the IPv4 stone.


Reverse that. IPv6 has impediments to adoption, which is why more time 
and resources are being spent to keep IPv4 usable until those 
impediments can be overcome.




IPv6 isn't perfect. That's not an excuse to ignore it and invest the 
limited resources we have into Yet Another IPv4 Zombification Effort.



As noted earlier, False Dilemma

Even worse, your thinking presupposes a finite amount of people-effort 
resources that must be properly managed by those superior in some 
fashion with more correct thinking.


I hope you can see when focused in that fashion all that is wrong with 
that viewpoint.


Joe

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Mark Andrews]

That fine. XP supports IPv6 and apart from the DNS needing a IPv4 recursive 
server it works fine. 

-- 
Mark Andrews

> On 21 Nov 2021, at 11:23, ML  wrote:
> 
> 
> 
>> On 11/19/2021 1:27 PM, William Herrin wrote:
>>> On Fri, Nov 19, 2021 at 10:22 AM Zu  wrote:
>>> One anecdote (the non-technical grandma) illustrates a very real problem 
>>> that would need to be addressed -- there are non-technical people (of all 
>>> ages, if your concerned about ageism) which will need to implement 
>>> technical changes for which they are not equipped with the skills to do.
>> Howdy,
>> 
>> That depends on your timeline. Do you know many non-technical people
>> still using their Pentium III computers with circa 2001 software
>> versions? Connected to the Internet?
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
> 
> A huge chunk of a country (Armenia) still using Windows XP...
> 
> https://en.wikipedia.org/wiki/Windows_XP#Market_share

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[ML]

On 11/19/2021 1:27 PM, William Herrin wrote:

On Fri, Nov 19, 2021 at 10:22 AM Zu  wrote:

One anecdote (the non-technical grandma) illustrates a very real problem that 
would need to be addressed -- there are non-technical people (of all ages, if 
your concerned about ageism) which will need to implement technical changes for 
which they are not equipped with the skills to do.

Howdy,

That depends on your timeline. Do you know many non-technical people
still using their Pentium III computers with circa 2001 software
versions? Connected to the Internet?

Regards,
Bill Herrin




A huge chunk of a country (Armenia) still using Windows XP...

https://en.wikipedia.org/wiki/Windows_XP#Market_share

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Gaurav Kansal]

> On 20-Nov-2021, at 02:21, g...@toad.com wrote:
> 
> David Conrad  wrote:
>> Doesn't this presume the redeployed addresses would be allocated
>> via a market rather than via the RIRs?
>> 
>> If so, who would receive the money?
> 
> You ask great questions.
> 
> The community can and should do the engineering to extend the IP
> implementations.  If that doesn't happen, the rest of the issues are
> moot.  There would be no addresses to allocate and no money to receive.
> 
> It would take multiple years post-RFC and post-implementation before
> anyone could even contemplate doing allocation, of any sort.  So while
> it's an entertaining sideline to think about later, at this point it is
> a distraction.
> 
>   John
>   
> PS:  It's conceivable that RIRs could allocate via a market.
> One has already done so (APNIC).
What exactly APNIC has done (just for curiosity) ? 

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Owen DeLong via NANOG]

> On Nov 19, 2021, at 12:11 , Jim  wrote:
> 
> On Thu, Nov 18, 2021 at 8:24 PM David Conrad  wrote:
>> 
> ...
>> Some (not me) might argue it could (further) hamper IPv6 deployment by 
>> diverting limited resources.
> 
> It may help IPv6 deployment if more V4 addresses are eventually
> released and allocated
> Assuming the RIRs would ultimately like to provision the usage of
> addresses within their own policies
> that the new address releases are exclusively for  'IPv6 Transition
> Tech.',  such as CGN NAT addresses,

CGN NAT is NOT a transition technology.

DS-LITE is an example of a transition technology 

CGN-NAT is an example of an avoidance of transition technology.

Owen

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Owen DeLong via NANOG]

> On Nov 19, 2021, at 11:46 , John Gilmore  wrote:
> 
> Joe Maimon  wrote:
>> And all thats needed to be done is to drop this ridiculous .0 for 
>> broadcast compatibility from standards.why is this even controversial?
> 
> Not to put words in his mouth, but that's how original BSD maintainer
> Mike Karels seemed to feel when we raised this issue for FreeBSD.  He
> was like, what?  We're wasting an address per subnet for 4.2BSD
> compatability?  Since 1986?  Let's fix that.
> 
>   John

Don’t get me started on BSD vs. IETF Standards… The whole stupidity
around VRRP and CARP still irritates me, so I don’t think holding up
the BSD attitude towards network standards is helping your case any.

Owen

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Owen DeLong via NANOG]

> On Nov 19, 2021, at 10:22 , John Curran  wrote:
> 
> On 18 Nov 2021, at 8:14 PM, b...@theworld.com  
> wrote:
>> That suggests an idea:
>> 
>> Repurpose these addresses and allow the RIRs to sell them in the IPv4
>> secondary markets with some earmark for the funds. Plus or minus
>> perhaps some worthy causes for "free" (not quite free but old school)
>> allocations. ...
> 
> (Sidestepping for the moment the question of technical merits of the 
> proposal…) 
> 
> There’s this organization called the Internet Engineering Task Force that has 
> been working hard to establish long-term financial independence and stability 
> via the IETF Endowment project  > –
> 
> Several of the Internet community organizations have made substantial 
> contributions to this goal, but much more will be needed if the IETF is to 
> achieve long-term funding stability.  Speaking entirely in my own personal 
> capacity, I believe that long-term financial stability of the IETF is an 
> extremely worthwhile goal for all of us to support and – to the extent that 
> somehow changes to the IPv4 address specification result in a financial 
> upside – I believe that the IETF Endowment would be a very appropriate 
> beneficiary.

Perhaps this would be a good use of the ICANN Make Money Fast scheme^w^w^w^wNew 
TLD fund.

Owen

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Tom Beecher]

>
> It may help IPv6 deployment if more V4 addresses are eventually
> released and allocated
>

No, it won't.

The biggest impediment to IPv6 adoption is that too many people invest too
much time and resources in finding ways to squeeze more blood from the IPv4
stone.

If tomorrow, RFCs were changed so every last address in the V4 space that
could be re-purposed for public use was :

- Every last one of these new IPs would be allocated years before the
majority of network devices and end hosts received software updates to work
properly.
- In the interim, a messy situation would exist with different endpoints
unable to reach endpoints numbered in these spaces , creating operational
nightmares for ISPs who frankly already have operational nightmares.
- At the end of this period when it's all figured out, we're right back
where we started. IPv4 will again be completely exhausted , and no more
going back to the well to redefine sections to get more of it.

IPv6 isn't perfect. That's not an excuse to ignore it and invest the
limited resources we have into Yet Another IPv4 Zombification Effort.

On Fri, Nov 19, 2021 at 3:12 PM Jim  wrote:

> On Thu, Nov 18, 2021 at 8:24 PM David Conrad  wrote:
> >
> ...
> > Some (not me) might argue it could (further) hamper IPv6 deployment by
> diverting limited resources.
>
> It may help IPv6 deployment if more V4 addresses are eventually
> released and allocated
> Assuming the RIRs would ultimately like to provision the usage of
> addresses within their own policies
> that the new address releases are exclusively for  'IPv6 Transition
> Tech.',  such as CGN NAT addresses,
> And make the proviso that new Allocations should be revoked/reduced on
> the basis of Non-Use alone  if found not
> being used highly-efficiently --- reducing the cost of  "New" V4
> addresses  but Restricting who can get the
> allocations and for what..  May make the scarcity "Fairer"  between
> Older existing Network Service Providers
> versus  Brand new Network Service Providers  who did not get to start
> with pre-assigned IPv4,
>  thus Helping V6 deployment.
>
> An important thing to hamper IPv6 deployment is bound to
> be newfound difficulty getting IPv4 numbers, and there are a large number
> of
> hosting and access network service providers pre-distributed IPv4,  so
> currently IPv4 is
> scarce enough to discourage new providers deploying IPv6 (because it
> will discourage
> new providers starting and making any networks at all), But  because of
> existing
> assignments, IPv4 is not scarce enough for existing providers to feel
> immediate pressure or need/desire to provide end to end IPv6 connectivity
> ---
> not when they can potentially pay up for more IPv4 and gobble up other
> NSPs through
> acquisitions.
>
> IPv4 numbers are required in order for network service providers to
> deploy IPv6 to
> subscribers, and for those subscribers to have connectivity to the
> majority of networks
> --- If you cannot get the IPv4, then more likely that new network
> service provider
> does not get created and offer service in the first place.   Alternatively
> new service providers find a costly source of some IPv4 numbers and pay up
> only to result in eventual necessity of deploying IPv6 services at a
> higher-price:
> it places existing providers with legacy IPv4 assignments at competitive
> advantage, and gives existing providers reason to decline or delay fully
> deploying IPv6 end-to-end.
>
>
> Even if you want to give your Subscribers IPv6 only and utilize no V4
> addresses for them
> like some large mobile providers;  you still end up needing a
> technology such as 464XLAT
> or CGN in the end,  and you are still going to require a substantial
> sum of IPv4 addresses
> in order to do it.
>
> >
> > > What will it *cost* to upgrade
> > > every node on the Internet?  And *how long* might it take?
>
> You need an upgrade timeframe for "cost to upgrade" to make sense.  It
> is unlikely any node will proceed forever without any upgrades - After
> a sufficient number of years, or decades have passed;  You will get to
> a point where every node, or almost every node had to have new
> software or replacement hardware for multiple reasons at some point,
> once a new version of Windows fixes your issue,  your one IPv4 tweak
> is 0.001% of the cost or less of the new version release..For
> example,  Windows XP devices are almost nowhere to be seen anymore,
> less than 1%   -   If the time frame is about 5 years,  then by that
> time most server/personal computers ought to have been replaced, or at
> least running a newer major OS version.
>
> The upgrade have a cost, but at that point there are numerous reasons
> it is required, and the upgrade cost is subsumed by the cost required
> just to maintain any system  (With 5+ years, the upgrade cost goes
> down to almost zero compared to the cumulative Annual
> upkeep/depreciation).
>
> Of course upgrades that must be done immediately, or within a short
> schedule 

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[John Gilmore]

David Conrad  wrote:
> Doesn't this presume the redeployed addresses would be allocated
> via a market rather than via the RIRs?
> 
> If so, who would receive the money?

You ask great questions.

The community can and should do the engineering to extend the IP
implementations.  If that doesn't happen, the rest of the issues are
moot.  There would be no addresses to allocate and no money to receive.

It would take multiple years post-RFC and post-implementation before
anyone could even contemplate doing allocation, of any sort.  So while
it's an entertaining sideline to think about later, at this point it is
a distraction.

John

PS:  It's conceivable that RIRs could allocate via a market.
One has already done so (APNIC).

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[John Gilmore]

Fred Baker  wrote:
> I tend to think that if we can somehow bless a prefix and make be
> global unicast address space, it needs to become Global Unicast
> Address Space.

Yes, I agree.  The intention is that with the passage of time, each
prefix becomes more and more reachable, til it's as close to 100% as any
other IP address.

I was just suggesting a side point, that some kinds of IP users may be
able to make earlier use of measurably less-reachable addresses.  That
could possibly enable them to get those addresses at lower prices (and
with no guarantees), compared to people who want and expect 100%
reachable IP addresses.  Having users making actual early use of them
would also encourage those users to actively work to improve their
reachability, rather than passively waiting til "somebody else" improves
their reachability.  (Indeed, some adventurous early adopters might buy
such addresses, actively improve their reachability, then 'flip' them
for higher prices, as some people do with real-estate.)  Just pointing
out a side chance for a win-win situation.  Most users would wait til
surveys show high reachability.

John

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[John Gilmore]

Nick Hilliard wrote:
>>   consider three hosts on a broadcast domain: A, B and 
>> C.  A uses the lowest address, B accepts a lowest address, but C does 
>> not.  Then A can talk to B, B can talk to C, but C cannot talk to A.  
>> This does not seem to be addressed in the draft.

Section 3.4.  Compatibility and Interoperability.

   Many deployed systems follow older Internet standards in not allowing
   the lowest address in a network to be assigned or used as a source or
   destination address.  Assigning this address to a host may thus make
   it inaccessible by some devices on its local network segment.   [there's
   more...]

If you think that section needs improving, please send suggested text.
We're happy to explain the implications better.

Joe Maimon  wrote:
> its a local support issue only.

That's also true.  The only issues arise between your devices, on your
LAN.  Everybody else on the Internet is unaffected and can reach all
your devices, including the lowest if your LAN uses it.  Nothing forces
you to use your lowest address, and we recommend that DHCP servers be
configured by default to not to hand them out (no change from how they
historically have been configured).

We submitted a 6-line patch to the Busybox DHCP implementation in
February to avoid hardcoded prevention of issuing a .0 or .255 address
(which was wrong anyway, even without our proposal).  The default in the
config file continues to use a range excluding .0.  The patch was merged
upstream without trouble.  See:

  
https://github.com/schoen/unicast-extensions/blob/master/merged-patches/busybox/0001-Don-t-hardcode-refusing-to-issue-.0-or-.255-addresse.patch
  
John

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Jim]

On Thu, Nov 18, 2021 at 8:24 PM David Conrad  wrote:
>
...
> Some (not me) might argue it could (further) hamper IPv6 deployment by 
> diverting limited resources.

It may help IPv6 deployment if more V4 addresses are eventually
released and allocated
Assuming the RIRs would ultimately like to provision the usage of
addresses within their own policies
that the new address releases are exclusively for  'IPv6 Transition
Tech.',  such as CGN NAT addresses,
And make the proviso that new Allocations should be revoked/reduced on
the basis of Non-Use alone  if found not
being used highly-efficiently --- reducing the cost of  "New" V4
addresses  but Restricting who can get the
allocations and for what..  May make the scarcity "Fairer"  between
Older existing Network Service Providers
versus  Brand new Network Service Providers  who did not get to start
with pre-assigned IPv4,
 thus Helping V6 deployment.

An important thing to hamper IPv6 deployment is bound to
be newfound difficulty getting IPv4 numbers, and there are a large number of
hosting and access network service providers pre-distributed IPv4,  so
currently IPv4 is
scarce enough to discourage new providers deploying IPv6 (because it
will discourage
new providers starting and making any networks at all), But  because of existing
assignments, IPv4 is not scarce enough for existing providers to feel
immediate pressure or need/desire to provide end to end IPv6 connectivity ---
not when they can potentially pay up for more IPv4 and gobble up other
NSPs through
acquisitions.

IPv4 numbers are required in order for network service providers to
deploy IPv6 to
subscribers, and for those subscribers to have connectivity to the
majority of networks
--- If you cannot get the IPv4, then more likely that new network
service provider
does not get created and offer service in the first place.   Alternatively
new service providers find a costly source of some IPv4 numbers and pay up
only to result in eventual necessity of deploying IPv6 services at a
higher-price:
it places existing providers with legacy IPv4 assignments at competitive
advantage, and gives existing providers reason to decline or delay fully
deploying IPv6 end-to-end.


Even if you want to give your Subscribers IPv6 only and utilize no V4
addresses for them
like some large mobile providers;  you still end up needing a
technology such as 464XLAT
or CGN in the end,  and you are still going to require a substantial
sum of IPv4 addresses
in order to do it.

>
> > What will it *cost* to upgrade
> > every node on the Internet?  And *how long* might it take?

You need an upgrade timeframe for "cost to upgrade" to make sense.  It
is unlikely any node will proceed forever without any upgrades - After
a sufficient number of years, or decades have passed;  You will get to
a point where every node, or almost every node had to have new
software or replacement hardware for multiple reasons at some point,
once a new version of Windows fixes your issue,  your one IPv4 tweak
is 0.001% of the cost or less of the new version release..For
example,  Windows XP devices are almost nowhere to be seen anymore,
less than 1%   -   If the time frame is about 5 years,  then by that
time most server/personal computers ought to have been replaced, or at
least running a newer major OS version.

The upgrade have a cost, but at that point there are numerous reasons
it is required, and the upgrade cost is subsumed by the cost required
just to maintain any system  (With 5+ years, the upgrade cost goes
down to almost zero compared to the cumulative Annual
upkeep/depreciation).

Of course upgrades that must be done immediately, or within a short
schedule are more expensive.

--
-JH

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[John Gilmore]

Joe Maimon  wrote:
> And all thats needed to be done is to drop this ridiculous .0 for 
> broadcast compatibility from standards.why is this even controversial?

Not to put words in his mouth, but that's how original BSD maintainer
Mike Karels seemed to feel when we raised this issue for FreeBSD.  He
was like, what?  We're wasting an address per subnet for 4.2BSD
compatability?  Since 1986?  Let's fix that.

John

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Michael Thomas]

On 11/19/21 10:15 AM, William Herrin wrote:

On Fri, Nov 19, 2021 at 10:04 AM Michael Thomas  wrote:

I don't think you can overstate how ASIC's made changing anything pretty
much impossible.
It's why all of the pissing and moaning about what ipv6 looked like
completely missed the point. There was a fuse lit in 1992 to when the
first hardware based routing was done. *Anything* that extended the
address space would have been better.

Obligatory 2007 plug: https://bill.herrin.us/network/ipxl.html


And just as impossible since it would pop it out of the fast path. Does 
big iron support ipv6 these days?


Mike

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Joe Maimon]

Zu wrote:

One anecdote (the non-technical grandma) illustrates a very real problem that 
would need to be addressed -- there are non-technical people (of all ages, if 
your concerned about ageism) which will need to implement technical changes for 
which they are not equipped with the skills to do.

They do not. Only if they want the extra address. Otherwise they are no 
worse off.


Unless of course their ISP somehow decides its a good idea to put their 
router on the allzero, but you cant fix stupid.


Joe

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[William Herrin]

On Fri, Nov 19, 2021 at 10:32 AM John Curran  wrote:
> There’s this organization called the Internet Engineering Task Force that has 
> been working hard to establish long-term financial independence and stability 
> via the IETF Endowment project  –
>
> Several of the Internet community organizations have made substantial 
> contributions to this goal, but much more will be needed if the IETF is to 
> achieve long-term funding stability.  Speaking entirely in my own personal 
> capacity, I believe that long-term financial stability of the IETF is an 
> extremely worthwhile goal for all of us to support and – to the extent that 
> somehow changes to the IPv4 address specification result in a financial 
> upside – I believe that the IETF Endowment would be a very appropriate 
> beneficiary.

Hi John,

That has some clever layers of subtlety to it. Instead of the IETF
having to decide when the IPv4 changes have a wide enough deployment
to release the addresses for use, they can simply make them available
for sale with proceeds to the endowment. When would-be buyers decide
they're good enough they'll be bought and used.

Regards,
Bill Herrin


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

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[William Herrin]

On Fri, Nov 19, 2021 at 10:22 AM Zu  wrote:
> One anecdote (the non-technical grandma) illustrates a very real problem that 
> would need to be addressed -- there are non-technical people (of all ages, if 
> your concerned about ageism) which will need to implement technical changes 
> for which they are not equipped with the skills to do.

Howdy,

That depends on your timeline. Do you know many non-technical people
still using their Pentium III computers with circa 2001 software
versions? Connected to the Internet?

Regards,
Bill Herrin


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

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[John Curran]

On 18 Nov 2021, at 8:14 PM, b...@theworld.com wrote:
> That suggests an idea:
> 
> Repurpose these addresses and allow the RIRs to sell them in the IPv4
> secondary markets with some earmark for the funds. Plus or minus
> perhaps some worthy causes for "free" (not quite free but old school)
> allocations. ...

(Sidestepping for the moment the question of technical merits of the proposal…) 

There’s this organization called the Internet Engineering Task Force that has 
been working hard to establish long-term financial independence and stability 
via the IETF Endowment project > –

Several of the Internet community organizations have made substantial 
contributions to this goal, but much more will be needed if the IETF is to 
achieve long-term funding stability.  Speaking entirely in my own personal 
capacity, I believe that long-term financial stability of the IETF is an 
extremely worthwhile goal for all of us to support and – to the extent that 
somehow changes to the IPv4 address specification result in a financial upside 
– I believe that the IETF Endowment would be a very appropriate beneficiary.

FYI,
/John

p.s.  Disclaimer: my views alone - contents may be hot and cause burns to 
unprotected surfaces. 
p.p.s.  It is unclear if the involvement of the RIRs in such a monetization 
activity is beneficial or not, but also orthogonal to the point that using 
proceeds for the benefit of IETF Endowment would be a very worthwhile goal. 

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[William Herrin]

On Fri, Nov 19, 2021 at 10:04 AM Michael Thomas  wrote:
> I don't think you can overstate how ASIC's made changing anything pretty
> much impossible.
> It's why all of the pissing and moaning about what ipv6 looked like
> completely missed the point. There was a fuse lit in 1992 to when the
> first hardware based routing was done. *Anything* that extended the
> address space would have been better.

Obligatory 2007 plug: https://bill.herrin.us/network/ipxl.html



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

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Zu]

One anecdote (the non-technical grandma) illustrates a very real problem that 
would need to be addressed -- there are non-technical people (of all ages, if 
your concerned about ageism) which will need to implement technical changes for 
which they are not equipped with the skills to do.

One anecdote (the technical grandma) holds no value, because the problem being 
discussed involves non-technical people having to upgrade equipment when they 
do not have the skills to do so. This anecdote serves no purpose, and 
illustrates nothing other than "certain people will be fine with technical 
changes" which we all already knew.

Obviously, a technically inclined person (of any age) will be better equipped 
to deal implementing a technical change. So, I am having trouble seeing how 
your "gotcha" counter-anecdote is of any value to the discussion.

Best,

Mu
‐‐‐ Original Message ‐‐‐

On Friday, November 19th, 2021 at 11:05 AM, Joe Maimon  
wrote:

> Nick Hilliard wrote:
>
> > Joe Maimon wrote on 19/11/2021 14:30:
> >
> > > Its very viable, since its a local support issue only. Your ISP can
> > >
> > > advise you that they will support you using the lowest number and you
> > >
> > > may then use it if you canall you may need is a single
> > >
> > > patched/upgraded router or firewall to get your additional static IP
> > >
> > > online.
> >
> > That would be an entertaining support phone call with grandma.
>
> Starting to get annoyed with ageism from tech nerds. Lots of grandma and
>
> grandpa computer geeks in existence these days. I think its time we
>
> start using great-grammy instead.
>
> > So, she gets a new CPE which issues 192.168.1.0 to her laptop and .1
> >
> > to her printer, and then her printer can no longer talk to her laptop.
>
> So she has a datacenter cab with a cat6a multi-gig drop and the ISP
>
> included in the price an on-link public /30, but more is gonna cost her,
>
> and this is for the non-profit she is running out of her SSI.
>
> Now she gets to use her link with two IP addresses instead of one,
>
> although she may have to click update firmware from the device's web
>
> interface, which might be harder than you think since she grew up using
>
> punch cards and these new fangled mouse thingies are a pain in her
>
> arthritic fingers, she'll take a CLI any day.
>
> She might use that for a redundant router, or for the second 443 port
>
> mapping inevitably required.
>
> Two can play the fake anecdote game.
>
> > I'm sure that the ISP would be happy to walk her through doing a
> >
> > firmware upgrade on her printer or that her day would end up better
> >
> > for having learned about DHCP assignment policies on her CPE.
> >
> > They could even email her a copy of the RFC and a link to the IETF
> >
> > working group if she felt there was a problem.
> >
> > Nick
>
> ISP's may very well be inclined to advise customers that a free extra IP
>
> is theirs for the taking should their equipment support it.
>
> Best,
>
> Joe

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Dave Taht]

On Fri, Nov 19, 2021 at 7:15 AM Nick Hilliard  wrote:
>
> Joe Maimon wrote on 19/11/2021 14:30:
> > Its very viable, since its a local support issue only. Your ISP can
> > advise you that they will support you using the lowest number and you
> > may then use it if you canall you may need is a single
> > patched/upgraded router or firewall to get your additional static IP
> > online.

This already works in many cases and the value of the extra IP address
declines as a function of the /cidr. /29s are pretty common.

> That would be an entertaining support phone call with grandma.
>
> So, she gets a new CPE which issues 192.168.1.0 to her laptop and .1 to
> her printer, and then her printer can no longer talk to her laptop.

In all honesty, I view the "zeroth" address as being primarily for
internet facing hosts on
small subnets, and not /24s, for the small businesses that are using
them today. A subset of 1 router,
1 device, needs to be checked for compatibility.

As for customer CPE RFC1918/24s, CeroWrt used /27s extensively in our
attempt to
route, rather than bridge wifi networks (to try and mitigate the wifi
multicast problem).
Remarkably we had only one end user device that did not deal with that properly
reported to us, (a sony dvd player) over the lifetime of the project.

Routing the home network as we did then did remarkably reduce wifi
multicast traffic,
but also exposed issues with mdns since solved. I would still rather
like it if we routed
guest and mesh networks rather than bridge them but that seems to be a
lost cause.

> I'm sure that the ISP would be happy to walk her through doing a
> firmware upgrade on her printer or that her day would end up better for
> having learned about DHCP assignment policies on her CPE.
>
> They could even email her a copy of the RFC and a link to the IETF
> working group if she felt there was a problem.

Setting up a home network with IPv6 only, and finding that printer, is
still hard today. Going back to mdns discovery, I recently found that
my new chromebook didn't support it, and can't print. Asking grandma
to type in fd87:3253:1343:deed:b33f:abd1:3217:1177 is no fun either.

>
> Nick



-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Michael Thomas]

On 11/19/21 7:38 AM, Owen DeLong via NANOG wrote:

Actually, CIDR didn’t require upgrading every end-node, just some of them.

That’s what made it doable… Updating only routers, not end-nodes.

Another thing that made it doable is that there were a LOT fewer end-nodes
and a much smaller vendor space when it came to the source of routers
that needed to be updated.

Further, in the CIDR deployment days, routers were almost entirely still
CPU-switched rather than ASIC or even line-card switched. Heck, the
workhorse backbone router that stimulated the development of CIDR
was built on an open-standard Mutlibus backplane with a MIPS CPU
IIRC. That also made widespread software updates a much simpler
proposition. Hardly anyone had a backbone router that was older than
an AGS (in fact, even the AGS was relatively rare in favor of the AGS+).


I don't think you can overstate how ASIC's made changing anything pretty 
much impossible. I'm not sure exactly then the cut over to ASIC's 
started to happen in the 90's, but once it did it was pretty much game 
over for ipv6. Instead of slipping an implementation into a release 
train and see what happens, it was getting buy in from a product manager 
that had absolutely no interest in respinning silicon. I remember when 
Deering and I were talking to the GSR folks (iirc) and it was hopeless 
since it would have to use the software path and nobody was going to buy 
a GSR for its software path.


It's why all of the pissing and moaning about what ipv6 looked like 
completely missed the point. There was a fuse lit in 1992 to when the 
first hardware based routing was done. *Anything* that extended the 
address space would have been better.


Mike

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Michael Thomas]

On 11/19/21 8:27 AM, Randy Bush wrote:

these measurements would be great if there could be a full research-
style paper, with methodology artifacts, and reproducible results.
otherwise it disappears in the gossip stream of mailimg lists.

Maybe an experimental rfc making it a rfc 1918-like subnet and 
implementing it on openwrt or something like that to see what happens. 
how many ip cameras and the like roll over and die? same for class E 
addresses too, I suppose. The question with anything that asks about 
legacy is how long the long tail actually is.


Mike, not that have any position on whether this is a good idea or not

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Owen DeLong via NANOG]

> On Nov 18, 2021, at 12:54 , John Gilmore  wrote:
> 
> Steven Bakker  wrote:
>> The ask is to update every ip stack in the world (including validation,
>> equipment retirement, reconfiguration, etc)...
> 
> This raises a great question.
> 
> Is it even *doable*?  What's the *risk*?  What will it *cost* to upgrade
> every node on the Internet?  And *how long* might it take?
> 
> We succeeded in upgrading every end-node and every router in the
> Internet in the late '90s and early 2000's, when we deployed CIDR.  It
> was doable.  We know that because we did it!  (And if we hadn't done it,
> the Internet would not have scaled to world scale.)

Actually, CIDR didn’t require upgrading every end-node, just some of them.

That’s what made it doable… Updating only routers, not end-nodes.

Another thing that made it doable is that there were a LOT fewer end-nodes
and a much smaller vendor space when it came to the source of routers
that needed to be updated.

Further, in the CIDR deployment days, routers were almost entirely still
CPU-switched rather than ASIC or even line-card switched. Heck, the
workhorse backbone router that stimulated the development of CIDR
was built on an open-standard Mutlibus backplane with a MIPS CPU
IIRC. That also made widespread software updates a much simpler
proposition. Hardly anyone had a backbone router that was older than
an AGS (in fact, even the AGS was relatively rare in favor of the AGS+).

I’d venture to guess that something north of 90% of BGP-speaking routers
were running IOS of the day (version 8.something, if memory serves).
Juniper didn’t exist yet. Arista didn’t exist yet. Foundry? Nope.
etc.

Proteon was mostly out of business and didn’t really make anything in that
class. Wellfleet did, but they had a very small market share.

The lift is a lot harder today and the potential benefits continue to shrink.

> That may not be worth it to you.  Or to your friends.  But it would be
> useful to a lot of people -- hundreds of millions of people who you may
> never know.  People who didn't get IP addresses when they were free,
> people outside the US and Europe, who will be able to buy and use them
> in 5 or 10 years, rather than leaving them unused and rotting on the
> vine.

I question this assertion. I might buy tens of thousands of people, but I find
it pretty hard to give credibility to the idea that this would make a 
significant
difference to hundreds of millions of people. It’s not going to reduce NAT
or CGN deployment significantly. It’s not going to speed up IPv6 deployment
in any meaningful way.

You’re going to have to make a much stronger case for the benefit here
being significant if you want that argument to be taken seriously.

Owen

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Randy Bush]

these measurements would be great if there could be a full research-
style paper, with methodology artifacts, and reproducible results.
otherwise it disappears in the gossip stream of mailimg lists.

randy

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Joe Maimon]

Nick Hilliard wrote:

Joe Maimon wrote on 19/11/2021 14:30:
Its very viable, since its a local support issue only. Your ISP can 
advise you that they will support you using the lowest number and you 
may then use it if you canall you may need is a single 
patched/upgraded router or firewall to get your additional static IP 
online.


That would be an entertaining support phone call with grandma.

Starting to get annoyed with ageism from tech nerds. Lots of grandma and 
grandpa computer geeks in existence these days. I think its time we 
start using great-grammy instead.


So, she gets a new CPE which issues 192.168.1.0 to her laptop and .1 
to her printer, and then her printer can no longer talk to her laptop.


So she has a datacenter cab with a cat6a multi-gig drop and the ISP 
included in the price an on-link public /30, but more is gonna cost her, 
and this is for the non-profit she is running out of her SSI.


Now she gets to use her link with two IP addresses instead of one, 
although she may have to click update firmware from the device's web 
interface, which might be harder than you think since she grew up using 
punch cards and these new fangled mouse thingies are a pain in her 
arthritic fingers, she'll take a CLI any day.


She might use that for a redundant router, or for the second 443 port 
mapping inevitably required.


Two can play the fake anecdote game.


I'm sure that the ISP would be happy to walk her through doing a 
firmware upgrade on her printer or that her day would end up better 
for having learned about DHCP assignment policies on her CPE.


They could even email her a copy of the RFC and a link to the IETF 
working group if she felt there was a problem.


Nick

ISP's may very well be inclined to advise customers that a free extra IP 
is theirs for the taking should their equipment support it.


Best,

Joe

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Joe Provo]

On Thu, Nov 18, 2021 at 11:37:49AM -0800, John Gilmore wrote:
> Steven Bakker  wrote:
> > > ... the gain is 4 weeks of
> > > extra ip address space in terms of estimated consumption.
> >
> > The burn rate is the best argument I've seen against the idea so far.
> 
> I'm glad you think so, since it's easy to refute.
[snip]
> Now that has ended, and addresses actually cost money in a real market.
[snip more market market market]

"Ended" is an interesting word, given distributions continue 
from the RIRs (eg https://www.arin.net/resources/guide/ipv4/waiting_list/)
as resources are available. Should any one of these ...imaginative
schemes come to pass and drop shiny new v4 space into the IANA
hopper, please do point to the policy where they would be 
distributed in a manner inconsistent with the RIR system, as
your post focused on the secondry transfer market.

The transfer market came into being as a tool to unlock stranded 
rights to use prefixes and a (too mild) friction to nudge IPv6
adoption. Should a pile of v4 be magically made available not
from existing stranded rights, the expectation that somehow
the market would be involved is odd to say the least. I would 
expect if this vein of "decades" of v4 were mined, the transfer
market should correctly react as any other supply/demand system
and prices would drop. 

Any presumptions about "burn rate influenced by pre-exhaustion
land rush" should  be sure to compare hard-landing (ARIN) and 
soft-landing RIRs. 

Cheers,

Joe 


-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling 

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Nick Hilliard]

Joe Maimon wrote on 19/11/2021 14:30:
Its very viable, since its a local support issue only. Your ISP can 
advise you that they will support you using the lowest number and you 
may then use it if you canall you may need is a single 
patched/upgraded router or firewall to get your additional static IP 
online.


That would be an entertaining support phone call with grandma.

So, she gets a new CPE which issues 192.168.1.0 to her laptop and .1 to 
her printer, and then her printer can no longer talk to her laptop.


I'm sure that the ISP would be happy to walk her through doing a 
firmware upgrade on her printer or that her day would end up better for 
having learned about DHCP assignment policies on her CPE.


They could even email her a copy of the RFC and a link to the IETF 
working group if she felt there was a problem.


Nick

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Joe Maimon]

Nick Hilliard wrote:

John Gilmore wrote on 19/11/2021 01:54:

Lowest address is in the most recent Linux and
FreeBSD kernels, but not yet in any OS distros.


lowest addresses will not be viable until widely supported on router 
(including CPE) platforms.  This is hard to test in the wild - ripe 
atlas will only test the transit path rather than the local 
connection. I.e. it's not clear that what you're measuring here is a 
valid way of working out whether a lowest address is generally going 
to work, because .0 has been mostly accepted in the transit path since 
the 1990s (bit alarming to see that it's still not universal).


The other risk with the lowest address proposal is that it will break 
network connectivity transitivity with no fallback or detection 
mechanism.  I.e. consider three hosts on a broadcast domain: A, B and 
C.  A uses the lowest address, B accepts a lowest address, but C does 
not.  Then A can talk to B, B can talk to C, but C cannot talk to A.  
This does not seem to be addressed in the draft.


Nick




Its very viable, since its a local support issue only. Your ISP can 
advise you that they will support you using the lowest number and you 
may then use it if you canall you may need is a single 
patched/upgraded router or firewall to get your additional static IP online.


The rest of the internet has no bearing on it.

Joe

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Jared Mauch]

> On Nov 18, 2021, at 4:31 PM, Randy Bush  wrote:
> 
> as a measurement kinda person, i wonder if anyone has looked at how much
> progress has been made on getting hard coded dependencies on D, E, 127,
> ... out of the firmware in all networked devices.


At least the E space is largely usable last I checked (eg: IOS-XR, JunOS).  You 
can even measure traceroutes that have the class-e space in them from some 
cloud providers if your network and the intermediaries don’t do u-rpf as well.

Most OS’es (MacOS, Linux, various *BSD) also permit this as well.  My 
understanding is that the RedmondOS may not handle this, but if you need to 
number your infrastructure these addresses may work well.

- Jared

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Nick Hilliard]

John Gilmore wrote on 19/11/2021 01:54:

Lowest address is in the most recent Linux and
FreeBSD kernels, but not yet in any OS distros.


lowest addresses will not be viable until widely supported on router 
(including CPE) platforms.  This is hard to test in the wild - ripe 
atlas will only test the transit path rather than the local connection. 
I.e. it's not clear that what you're measuring here is a valid way of 
working out whether a lowest address is generally going to work, because 
.0 has been mostly accepted in the transit path since the 1990s (bit 
alarming to see that it's still not universal).


The other risk with the lowest address proposal is that it will break 
network connectivity transitivity with no fallback or detection 
mechanism.  I.e. consider three hosts on a broadcast domain: A, B and C. 
 A uses the lowest address, B accepts a lowest address, but C does not. 
 Then A can talk to B, B can talk to C, but C cannot talk to A.  This 
does not seem to be addressed in the draft.


Nick

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[David Conrad]

> I would be happy to fund or run a project that would announce small
> global routes in each of these ranges, and do some network probing, to
> actually measure how well they work on the real Internet.

To be clear, despite my skepticism, I think this would be an interesting 
experiment to run.  I believe it would be useful to get some actual data on 
reachability/usefulness as the question of deployment of reserved space is a 
recurrent question, both in technical and political spaces.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[David Conrad]

John,

On Nov 18, 2021, at 12:54 PM, John Gilmore  wrote:
> Is it even *doable*?

With enough thrust, pigs fly quite well, although the landing can be messy.

> What's the *risk*?

Some (not me) might argue it could (further) hamper IPv6 deployment by 
diverting limited resources.

> What will it *cost* to upgrade
> every node on the Internet?  And *how long* might it take?

These are the pertinent questions, which are, of course extremely hard to 
estimate.

> We succeeded in upgrading every end-node and every router in the
> Internet in the late '90s and early 2000's, when we deployed CIDR.

My recollection was that CIDR deployment was a bit early than that, but 
regardless, the Internet of the late '90s and early 2000’s was vastly different 
than the Internet today.  For one thing, most of the end nodes still had people 
with technical clue managing them.  That’s not the case today.

> So today if we decide that unicast use of the 268 million addresses in
> 240/4 is worth doing, we can upgrade every node.

Can we?  We can’t even get some DNS resolvers to stop querying root server IP 
addresses that were renumbered two decades ago. People aren’t even 
patching/updating publicly available systems with active security exploits that 
are impacting them directly and you believe they’ll be willing to update all 
their devices to benefit other people (the ones who want the 240/4 space)?  You 
must be more optimistic than I.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Fred Baker]

Sent using a machine that autocorrects in interesting ways...

> On Nov 18, 2021, at 5:15 PM, John Gilmore  wrote:
> 
> Keeping the price of IPv4 addresses reasonable means that dual-stack
> servers can continue to be deployed at reasonable cost, so that it
> doesn't matter whether clients have IPv6 or IPv4.  Any company that put
> its services on IPv6-only sites today would be cutting off 65% of their
> potential customers.  Even if v6 had 90% of the market, why would a
> company want 10% of its prospects to be unable to reach its service?

I find myself thinking about Reliance JIO, an Indian company. Iirc, their IPv4 
and IPv6 statistics are in the slide deck they presented to the IETF a year or 
two back, and they came to me/us a little later wanting somehow expand the IPv4 
address pool. In short, most of their services are IPv6 only. The only thing 
they want IPv4 addresses for is their enterprise customers, who want an IPv4 
option wherever IPv6 is an option - so they don’t have to select IPv6.

That’s all we’ll and good if the IPv4 addresses exist and work globally.  
Someone (was it you?) noted earlier in the thread that it might be acceptable 
to provide IPv4 address space that only worked in certain places. I find myself 
thinking about the arguments for a global DNS root. What a regional IPv4 
connectivity limit creates is a network that doesn’t work everywhere, meaning 
that the government of <> will be incented to deploy that address space locally 
within their country and provide a national NAT firewall to somehow protect 
their citizens - because of course the bad guys are always somewhere else. Kind 
of like the US wants to regulate encryption because nobody outside the US uses 
it or whatever. WHATEVER!

I tend to think that if we can somehow bless a prefix and make be global 
unicast address space, it needs to become Global Unicast Address Space.

This is becoming a rant, so I’ll stop…

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[John Gilmore]

Randy Bush  wrote:
> as a measurement kinda person, i wonder if anyone has looked at how much
> progress has been made on getting hard coded dependencies on D, E, 127,
> ... out of the firmware in all networked devices.

The drafts each have an Implementation Status section that describes
what we know.  The authors would be happy to receive updates for any of
that information.

240/4 is widespread everywhere except in Microsoft products.  It works
so reliably that both Google and Amazon appear to be bootlegging it on
their internal networks.  Google even advises customers to use it:

  https://cloud.google.com/vpc/docs/vpc#valid-ranges

0/8, and the lowest address per subnet, have interoperable
implementations that don't cause problems with legacy equipment, but
they are not widely deployed.  0/8 has a few years in Linux & Android
kernels and distros.  Lowest address is in the most recent Linux and
FreeBSD kernels, but not yet in any OS distros.  In particular, OpenWRT
doesn't implement it yet, which could easily be a fast path to a free
extra IP address for anyone who has a compatible home router and a
globally routed small network like a /29.

We used RIPE Atlas to test the reachability of many addresses that end
in .0 and .0.0, and they were reachable from all but one probe that we
tried.  Amazon offers

  https://ec2-reachability.amazonaws.com/

for this purpose; try it on your own network!

Some embedded TCP stacks treat 127/8 as unicast (simply because they
don't special-case much of anything), but otherwise we don't know of any
current OS distributions that implement unicast for 127/8.  The Linux
kernel has long had a non-default "route_localnet" option offering
similar but more problematic behavior.

I would be happy to fund or run a project that would announce small
global routes in each of these ranges, and do some network probing, to
actually measure how well they work on the real Internet.  We are
working with RIPE Atlas already to enable this.  I thought it would be
prudent to propose the changes in detail to IETF, before "bogus" routes
showed up in BGP and the screaming on the NANOG list started.  :-/

John

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[David Conrad]

John,

On Nov 18, 2021, at 11:37 AM, John Gilmore  wrote:
> At current rates, 300 to 400 million addresses would last more than a decade!

Doesn’t this presume the redeployed addresses would be allocated via a market 
rather than via the RIRs?

If so, who would receive the money?

> There will be no future free-for-all that burns through 300 million IPv4 
> addresses in 4 months.

I suspect you underestimate the global demand and may not fully understand the 
rationale for address acquisition.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[bzs]

That suggests an idea:

Repurpose these addresses and allow the RIRs to sell them in the IPv4
secondary markets with some earmark for the funds. Plus or minus
perhaps some worthy causes for "free" (not quite free but old school)
allocations.

If you can't agree on any worthwhile earmark you can always send me
the proceeds.

-- 
-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: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[John Gilmore]

Fred Baker  wrote:
> My observation has been that people don't want to extend the life of
> IPv4 per se; people want to keep using it for another very short time
> interval and then blame someone else for the fact that the 32 bit
> integers are a finite set.

It's an attractive strawman, but knocking it down doesn't
contribute to the discussion.

I am not blaming anybody for the finity of 32-bit integers.

Nor am I trying to extend the lifetime of IPv4, for either a short or a
long time.  Personally, I think that IPv4 will already be with us for
the rest of my lifetime.  Its life will already extend beyond mine,
without any effort on my part.  It was a good design, and it will
outlive its makers.  The people who in 2008 predicted that it was
senseless to improve IPv4 because it would be dead by 2018, were
objectively wrong, because it's not dead.

IETF did what the objectors said, back in 2008: They didn't improve
IPv4, on the exact theory that effort would go into IPv6 instead.  Hmm.
13 years later, that decision did not cause IPv6 to take over the world
and obsolete IPv4.  IPv4 is still here, and the improvements that would
have been fully rolled out to the user base by now, if standardized in
2008, are still missing.  Perhaps we should reconsider that wrong
advice, rather than regurgitate the same decision every time the issue
is raised?

> If you don't think that's a true statement, I'd be very interested to
> hear what you think might be true.

IPv6 is still on a remarkable if not meteoric growth ramp; in the last
year it's gone from 30% to 34% of the Internet, according to Google.
There is no need to cut off IPv4 maintenance at the knees in order to
make IPv6 look good.  We can make both v4 and v6 better, and let people
choose which one(s) they prefer to use.

That's what I think might be true about why simple low-risk tweaks that
make IPv4 better are not an obviously stupid tactic.

As Brian Carpenter has been saying for 15+ years, IPv4 and IPv6 don't
have a transition strategy, they have a co-existence strategy.
Neglecting or abandoning IPv4 is not a useful part of that strategy.

Keeping the price of IPv4 addresses reasonable means that dual-stack
servers can continue to be deployed at reasonable cost, so that it
doesn't matter whether clients have IPv6 or IPv4.  Any company that put
its services on IPv6-only sites today would be cutting off 65% of their
potential customers.  Even if v6 had 90% of the market, why would a
company want 10% of its prospects to be unable to reach its service?

(Big companies who run massive public-facing server farms are the
biggest buyers of IPv4 addresses in the market, spending hundreds of
millions of dollars every year.  Amazon, Google, Alibaba, Microsoft,
etc.  They are already running IPv6, and all their servers already have
free IPv6 addresses from a RIR.  Why are they spending that money?
It isn't because they are stupid doodooheads who hate IPv6.)

As Fred points out, this issue has been discussed since 2008.  IETF also
faced it in 2014-2018 in the now-sunsetted "sunset4" working group.
That group wrote a bunch of drafts proposing to disable or sunset IPv4.
None of these became RFCs.  They didn't pass the sniff test.  They
weren't what users and customers wanted.

The issue keeps coming back because the wrong decision keeps getting
offered: "Just switch everybody to use IPv6, and if they won't, then
deny their proposals for IPv4."  Another way of putting it was proposed
by Dave Thaler: "Rather than changing any existing software (OS's or
apps) to allow class E addresses, the effort would be better spent
towards getting more IPv6 deployment."

This is not an objection to deploying reserved addresses in IPv4, it is
a plea for more IPv6 deployment.  It is like saying, "Do not spend your
time fixing the environment, instead we need to fix the political
system."

It is a hopeless plea, since "allowing Class E addresses" and "more IPv6
deployment" are not the only two possible goals to put forth effort on.
Merely stopping work on one, will not cause the other to be advanced.
There must be a name for this fallacious argument...thank you, Wikipedia,
it's a "false dilemma":

  https://en.wikipedia.org/wiki/False_dilemma

The two goals can proceed in parallel, and many of the people who would
happily do Goal 1 are not in any position to affect Goal 2 -- just as
with the environment and politics.

It's pretty simple to understand why IPv6 has not taken over the world
yet.  IPv4 got rapid adoption because it was so much better than all the
alternatives available at the time.  IPv6 would have gotten equally
rapid adoption if it had been the thing so much better than all the
alternatives.  IPv6 is not getting that rapid adoption today, because it
has to compete with the already pervasive IPv4.  IPv4 is better in one
key way: everybody you want to talk with is already there.  (It's akin
to the issue of why can't people just switch to a better social network
than Facebook?  

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Karsten Thomann via NANOG]

I find it a bit interesting to follow this thread...

There was a discussion in March where Douglas Fischer shared this 
picture which shows that Amazon is already using 240/4 space internally.

https://pasteboard.co/JRHNVKw.png
And I heard it from other sources, too (not an AWS customer so wont try 
to verify it).


Therefore it is probably nearly impossible to get it to public routeable.
In my opinion it is like RFC 1918, 10.64/10 CGN space or the reserved 
test networks.
Do what ever you want with it internally, but you won't get it into the 
DFZ.


The problem is not to get it routable, but to get it usable in a way 
that you could assign it to customers without causing massive support 
problems.


Am 18.11.2021 um 21:54 schrieb John Gilmore:

Steven Bakker  wrote:

The ask is to update every ip stack in the world (including validation,
equipment retirement, reconfiguration, etc)...

This raises a great question.

Is it even *doable*?  What's the *risk*?  What will it *cost* to upgrade
every node on the Internet?  And *how long* might it take?

We succeeded in upgrading every end-node and every router in the
Internet in the late '90s and early 2000's, when we deployed CIDR.  It
was doable.  We know that because we did it!  (And if we hadn't done it,
the Internet would not have scaled to world scale.)

So today if we decide that unicast use of the 268 million addresses in
240/4 is worth doing, we can upgrade every node.  If we do, we might as
well support unicast on the other 16 million addresses in 0/8, and the
16 million in 127/8, and the other about 16 million reserved for
4.2BSD's pre-standardized subnet broadcast address that nobody has used
since 1985.  And take a hard look at another hundred million addresses
in the vast empty multicast space, that have never been assigned by IANA
for anybody or anything.  Adding the address blocks around the edges
makes sense; you only have to upgrade everything once, but the 268
million addresses becomes closer to 400 million formerly wasted
addresses.  That would be worth half again as much to end users,
compared to just doing 240/4!

That may not be worth it to you.  Or to your friends.  But it would be
useful to a lot of people -- hundreds of millions of people who you may
never know.  People who didn't get IP addresses when they were free,
people outside the US and Europe, who will be able to buy and use them
in 5 or 10 years, rather than leaving them unused and rotting on the
vine.

We already know that making these one-line patches is almost risk-free.
240/4 unicast support is in billions of nodes already, without trouble.
Linux, Android, MacOS, iOS, and Solaris all started supporting unicast
use of 240/4 in 2008!  Most people -- even most people in NANOG --
didn't even notice.  0/8 unicast has been in Linux and Android kernels
for multiple years, again with no problems.  Unicast use of the lowest
address in each subnet is now in Linux and NetBSD, recently (see the
drafts for specifics).  If anyone knows of security issues that we
haven't addressed in the drafts, please tell us the details!  There has
been some arm-waving about a need to update firewalls, but most of these
addresses have been usable as unicast on LANs and private networks for
more than a decade, and nobody's reported any firewall vulnerabilities
to CERT.

Given the low risk, the natural way for these unicast extensions to roll
out is to simply include them in new releases of the various operating
systems and router OS's that implement the Internet protocols.  It is
already happening, we're just asking that the process be adopted
universally, which is why we wrote Internet-Drafts for IETF.  Microsoft
Windows is the biggest laggard; they drop any packet whose destination
OR SOURCE address is in 240/4.  When standards said 240/4 was reserved
for what might become future arcane (variable-length, anycast, 6to4,
etc) addressing modes, that made sense.  It doesn't make sense in 2021.
IPv4 is stable and won't be inventing any new addressing modes.  The
future is here, and all it wants out of 240/4 is more unicast addresses.

By following the normal OS upgrade path, the cost of upgrading is almost
zero.  People naturally upgrade their OS's every few years.  They
replace their server or laptop with a more capable one that has the
latest OS.  Laggards might take 5 or 10 years.  Peoples' home WiFi
routers break, or are upgraded to faster models, or they change ISPs and
throw the old one out, every 3 to 5 years.  A huge proportion of
end-users get automatic over-the-net upgrades, via an infrastructure
that had not yet been built for consumers during the CIDR transition.
"Patch Tuesday" could put some or all of these extensions into billions
of systems at scale, for a one-time fixed engineering and testing cost.

We have tested major routers, and none so far require software updates
to enable most of these addresses (except on the lowest address per
subnet).  At worst, the ISP would have to turn off 

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Joe Maimon]

Nick Hilliard wrote:

John Gilmore wrote on 18/11/2021 19:37:

There will be no future free-for-all that burns through 300 million
IPv4 addresses in 4 months.


this is correct not necessarily because of the reasons you state, but 
because all the RIRs have changed their ipv4 allocation policies to 
policies which assume complete or near-complete depletion of the 
available pools, rather than policies which allocate / assign on the 
basis of stated requirement.  For sure, organisations were previously 
requesting more than they needed, but if stated-requirement were 
reinstituted as a policy basis, the address space would disappear in a 
flash.


I think it more likely that organizations will treat new space like they 
do their reclaimed/returned allocations right now. We are not going 
back. IPv4 only becomes plentiful again upon obsolescence.


Need is elastic based upon general availability of supply. To say it 
differently, organizations were requesting more than than they 
absolutely required to get by. And that was ok, because there was no 
reason to require them to twist themselves into engineering pretzels 
when IPv4 was freely available.


Simple example, back in the day you could choose to deploy a T1 customer 
with a public /30 and routed /29 and that would have easily met needs 
requirements.


On the other hand, you could also deploy the same customer with 
unnumbered or private /30 and routed to loopback public /32.



The point remains that 127/8, 0/8, 240/4 are problematic to 
debogonise, and are not going to make a dramatic impact to the 
availability of ipv4 addresses in the longer term. Same with using the 
lowest ip address in a network block.  Nice idea, but 30 years late.


There's no problem implementing these ideas in code and quietly using 
the address space in private contexts.


Nick




Right or wrong, it would be nice to remove any impediment to the effort 
absent justifiable document-able and insurmountable reason why the space 
should NOT be usable.


And those impediments manifest themselves even for quietly using the 
address space in private contexts.


Also, the 30 intervening years have dramatically upped the stakes in 
terms of RoI.


I suggest considering these proposals in the light that IPv4 may be 
obsolete in a decade. And maybe not.


If it is obsolete, whats the harm?

And if it not, the benefits are clearer than ever.

Joe

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Randy Bush]

as a measurement kinda person, i wonder if anyone has looked at how much
progress has been made on getting hard coded dependencies on D, E, 127,
... out of the firmware in all networked devices.

randy

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[John Gilmore]

Steven Bakker  wrote:
> The ask is to update every ip stack in the world (including validation,
> equipment retirement, reconfiguration, etc)...

This raises a great question.

Is it even *doable*?  What's the *risk*?  What will it *cost* to upgrade
every node on the Internet?  And *how long* might it take?

We succeeded in upgrading every end-node and every router in the
Internet in the late '90s and early 2000's, when we deployed CIDR.  It
was doable.  We know that because we did it!  (And if we hadn't done it,
the Internet would not have scaled to world scale.)

So today if we decide that unicast use of the 268 million addresses in
240/4 is worth doing, we can upgrade every node.  If we do, we might as
well support unicast on the other 16 million addresses in 0/8, and the
16 million in 127/8, and the other about 16 million reserved for
4.2BSD's pre-standardized subnet broadcast address that nobody has used
since 1985.  And take a hard look at another hundred million addresses
in the vast empty multicast space, that have never been assigned by IANA
for anybody or anything.  Adding the address blocks around the edges
makes sense; you only have to upgrade everything once, but the 268
million addresses becomes closer to 400 million formerly wasted
addresses.  That would be worth half again as much to end users,
compared to just doing 240/4!

That may not be worth it to you.  Or to your friends.  But it would be
useful to a lot of people -- hundreds of millions of people who you may
never know.  People who didn't get IP addresses when they were free,
people outside the US and Europe, who will be able to buy and use them
in 5 or 10 years, rather than leaving them unused and rotting on the
vine.

We already know that making these one-line patches is almost risk-free.
240/4 unicast support is in billions of nodes already, without trouble.
Linux, Android, MacOS, iOS, and Solaris all started supporting unicast
use of 240/4 in 2008!  Most people -- even most people in NANOG --
didn't even notice.  0/8 unicast has been in Linux and Android kernels
for multiple years, again with no problems.  Unicast use of the lowest
address in each subnet is now in Linux and NetBSD, recently (see the
drafts for specifics).  If anyone knows of security issues that we
haven't addressed in the drafts, please tell us the details!  There has
been some arm-waving about a need to update firewalls, but most of these
addresses have been usable as unicast on LANs and private networks for
more than a decade, and nobody's reported any firewall vulnerabilities
to CERT.

Given the low risk, the natural way for these unicast extensions to roll
out is to simply include them in new releases of the various operating
systems and router OS's that implement the Internet protocols.  It is
already happening, we're just asking that the process be adopted
universally, which is why we wrote Internet-Drafts for IETF.  Microsoft
Windows is the biggest laggard; they drop any packet whose destination
OR SOURCE address is in 240/4.  When standards said 240/4 was reserved
for what might become future arcane (variable-length, anycast, 6to4,
etc) addressing modes, that made sense.  It doesn't make sense in 2021.
IPv4 is stable and won't be inventing any new addressing modes.  The
future is here, and all it wants out of 240/4 is more unicast addresses.

By following the normal OS upgrade path, the cost of upgrading is almost
zero.  People naturally upgrade their OS's every few years.  They
replace their server or laptop with a more capable one that has the
latest OS.  Laggards might take 5 or 10 years.  Peoples' home WiFi
routers break, or are upgraded to faster models, or they change ISPs and
throw the old one out, every 3 to 5 years.  A huge proportion of
end-users get automatic over-the-net upgrades, via an infrastructure
that had not yet been built for consumers during the CIDR transition.
"Patch Tuesday" could put some or all of these extensions into billions
of systems at scale, for a one-time fixed engineering and testing cost.

We have tested major routers, and none so far require software updates
to enable most of these addresses (except on the lowest address per
subnet).  At worst, the ISP would have to turn off or reconfigure a
bogon filter with a config setting.  Also, many "Martian address" bogon
lists are centrally maintained
(e.g. https://team-cymru.com/community-services/bogon-reference/ ) and
can easily be updated.  We have found no ASIC IP implementations that
hardwire in assumptions about specific IP address ranges.  If you know
of any, please let us know, otherwise, let's let that strawman rest.

Our drafts don't propose to choose between public and private use of the
newly usable unicast addresses (so the prior subject line that said
"unicast public" was incorrect).  Since the kernel and router
implementation is the same in either case, we're trying to get those
fixed first.  There will be plenty of years and plenty of forums (NANOG,
IETF, 

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Nick Hilliard]

John Gilmore wrote on 18/11/2021 19:37:

There will be no future free-for-all that burns through 300 million
IPv4 addresses in 4 months.


this is correct not necessarily because of the reasons you state, but 
because all the RIRs have changed their ipv4 allocation policies to 
policies which assume complete or near-complete depletion of the 
available pools, rather than policies which allocate / assign on the 
basis of stated requirement.  For sure, organisations were previously 
requesting more than they needed, but if stated-requirement were 
reinstituted as a policy basis, the address space would disappear in a 
flash.


The point remains that 127/8, 0/8, 240/4 are problematic to debogonise, 
and are not going to make a dramatic impact to the availability of ipv4 
addresses in the longer term.  Same with using the lowest ip address in 
a network block.  Nice idea, but 30 years late.


There's no problem implementing these ideas in code and quietly using 
the address space in private contexts.


Nick