Mailing List Archive

Steven Bakker <steven.bakker@ams-ix.net> 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, ICANN, IANA, and the RIRs) in which to wrestle the
public-vs-private questions to the ground and make community decisions
on actual allocations. But if we don't fix the kernels and routers
first, none of those decisions would be implementable.

Finally, as suggested by David Conrad, there is a well understood
process for "de-bogonizing" an address range on the global Internet,
once support for it exists in OS's. Cloudflare used it on 1.1.1.1; RIPE
used it on 128.0/16 and on 2a10::/12. You introduce a global BGP route
for some part of the range, stand up a server on it, and use various
distributed measurement testbeds to see who can reach that server. When
chunks of the Internet can't, an engineer figures out where the blockage
is, and communicates with that ISP or vendor to resolve the issue.
Lather, rinse and repeat for a year or more, until reachability is "high
enough".

Addresses that later end up allocated to private address blocks would
never need 100% global reachability, but global testing would still help
to locate low-volume OS implementations that might need to be updated.
Addresses bought to number retail cellphones need not be as reachable as
ones used on public-facing servers, etc. The beauty of a market for IP
addresses, rather than one-size-fits-all allocation models, is that ones
with different reachability can sell for different prices, at different
times, into different niches where they can be put to use.

John

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

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

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

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 <steven.bakker@ams-ix.net> 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, ICANN, IANA, and the RIRs) in which to wrestle the
> public-vs-private questions to the ground and make community decisions
> on actual allocations. But if we don't fix the kernels and routers
> first, none of those decisions would be implementable.
>
> Finally, as suggested by David Conrad, there is a well understood
> process for "de-bogonizing" an address range on the global Internet,
> once support for it exists in OS's. Cloudflare used it on 1.1.1.1; RIPE
> used it on 128.0/16 and on 2a10::/12. You introduce a global BGP route
> for some part of the range, stand up a server on it, and use various
> distributed measurement testbeds to see who can reach that server. When
> chunks of the Internet can't, an engineer figures out where the blockage
> is, and communicates with that ISP or vendor to resolve the issue.
> Lather, rinse and repeat for a year or more, until reachability is "high
> enough".
>
> Addresses that later end up allocated to private address blocks would
> never need 100% global reachability, but global testing would still help
> to locate low-volume OS implementations that might need to be updated.
> Addresses bought to number retail cellphones need not be as reachable as
> ones used on public-facing servers, etc. The beauty of a market for IP
> addresses, rather than one-size-fits-all allocation models, is that ones
> with different reachability can sell for different prices, at different
> times, into different niches where they can be put to use.
>
> John

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 | bzs@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*

John,

On Nov 18, 2021, at 11:37 AM, John Gilmore <gnu@toad.com> 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

Randy Bush <randy@psg.com> 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

John,

On Nov 18, 2021, at 12:54 PM, John Gilmore <gnu@toad.com> 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

> 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

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

> On Nov 18, 2021, at 4:31 PM, Randy Bush <randy@psg.com> 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

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

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

On Fri, Nov 19, 2021 at 7:15 AM Nick Hilliard <nick@foobar.org> 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 can....all 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

> On Nov 18, 2021, at 12:54 , John Gilmore <gnu@toad.com> wrote:
>
> Steven Bakker <steven.bakker@ams-ix.net> 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

On Thu, Nov 18, 2021 at 11:37:49AM -0800, John Gilmore wrote:
> Steven Bakker <steven.bakker@ams-ix.net> 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

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

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

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 <jmaimon@jmaimon.com> 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 can....all 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

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

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

On Fri, Nov 19, 2021 at 10:04 AM Michael Thomas <mike@mtcc.com> 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
bill@herrin.us
https://bill.herrin.us/

On 18 Nov 2021, at 8:14 PM, bzs@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 <https://www.ietf.org/endowment/ <https://www.ietf.org/endowment/>> –

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.