Mailing List Archive

On Fri, Nov 19, 2021 at 10:22 AM Zu <mu@zuqq.me> 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
bill@herrin.us
https://bill.herrin.us/

On Fri, Nov 19, 2021 at 10:32 AM John Curran <jcurran@istaff.org> 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 <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.

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
bill@herrin.us
https://bill.herrin.us/

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

On 11/19/21 10:15 AM, William Herrin wrote:
> 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
>
>
And just as impossible since it would pop it out of the fast path. Does
big iron support ipv6 these days?

Mike

On Thu, Nov 18, 2021 at 8:24 PM David Conrad <drc@virtualized.org> 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

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

David Conrad <drc@virtualized.org> 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).

It appears that Michael Thomas <mike@mtcc.com> said:
>And just as impossible since it would pop it out of the fast path. Does
>big iron support ipv6 these days?

My research associate Ms. Google advises me that Juniper does:

https://www.juniper.net/documentation/us/en/software/junos/routing-overview/topics/concept/ipv6-technology-overview.html

As does Cisco:

https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9600-series-switches/nb-06-cat9600-ser-sup-eng-data-sheet-cte-en.pdf

R's,
John

On 11/19/21 2:44 PM, John Levine wrote:
> It appears that Michael Thomas <mike@mtcc.com> said:
>> And just as impossible since it would pop it out of the fast path. Does
>> big iron support ipv6 these days?
> My research associate Ms. Google advises me that Juniper does:
>
> https://www.juniper.net/documentation/us/en/software/junos/routing-overview/topics/concept/ipv6-technology-overview.html
>
> As does Cisco:
>
> https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9600-series-switches/nb-06-cat9600-ser-sup-eng-data-sheet-cte-en.pdf
>
> R's,

Both have sprawling product lines though even with fsvo big iron. It
would be nice to hear that they can build out big networks, but given
the use of ipv6 in mobile I assume they can. I wonder what the situation
is for enterprise which doesn't have any direct drivers that I know of.

Mike

>
> 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 <mysidia@gmail.com> wrote:

> On Thu, Nov 18, 2021 at 8:24 PM David Conrad <drc@virtualized.org> 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
>

It appears that Michael Thomas <mike@mtcc.com> said:
>Both have sprawling product lines though even with fsvo big iron. It
>would be nice to hear that they can build out big networks, but given
>the use of ipv6 in mobile I assume they can. I wonder what the situation
>is for enterprise which doesn't have any direct drivers that I know of.

Google says they see about 1/3 of their users on IPv6 so I presume they
are getting their routers from someone. As you note, many mobile networks
are IPv6 internally, and they seem to work.

R's,
John

Cisco and Juniper routers have had v6 functionality for over 10 years.
Lucent/Nokia, and others. Check UNL list at
https://www.iol.unh.edu/registry/usgv6 for v6 compliant routers and
switches.

John Lee

On Fri, Nov 19, 2021 at 5:48 PM John Levine <johnl@iecc.com> wrote:

> It appears that Michael Thomas <mike@mtcc.com> said:
> >And just as impossible since it would pop it out of the fast path. Does
> >big iron support ipv6 these days?
>
> My research associate Ms. Google advises me that Juniper does:
>
>
> https://www.juniper.net/documentation/us/en/software/junos/routing-overview/topics/concept/ipv6-technology-overview.html
>
> As does Cisco:
>
>
> https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9600-series-switches/nb-06-cat9600-ser-sup-eng-data-sheet-cte-en.pdf
>
> R's,
> John
>

Speed of router depends on degree of parallelism.

So, for quick routing table lookup, if you provide 128bit TCAM
for IPv6 in addition to 32bit TCAM for IPv4, speed is mostly
same, though, for each entry, TCAM for IPv6 costs 4 times more
and consumes 4 times more power than that for IPv4.

However, as global routing table size of IPv6 is a lot smaller
than that of IPv4, the number of the entries of TCAM for IPv6
is a lot smaller than that for IPv4. But it is so primarily
because IPv6 is not very widely deployed.

Or, if you perform IPv6 address look up by software, IPv6 is
slower.

Masataka Ohta

> On 20-Nov-2021, at 02:21, gnu@toad.com wrote:
>
> David Conrad <drc@virtualized.org> 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) ?

> On Nov 19, 2021, at 10:22 , John Curran <jcurran@istaff.org> wrote:
>
> On 18 Nov 2021, at 8:14 PM, bzs@theworld.com <mailto: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.

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

Owen

> On Nov 19, 2021, at 12:11 , Jim <mysidia@gmail.com> wrote:
>
> On Thu, Nov 18, 2021 at 8:24 PM David Conrad <drc@virtualized.org> 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

> On Nov 20, 2021, at 00:41 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> Speed of router depends on degree of parallelism.
>
> So, for quick routing table lookup, if you provide 128bit TCAM
> for IPv6 in addition to 32bit TCAM for IPv4, speed is mostly
> same, though, for each entry, TCAM for IPv6 costs 4 times more
> and consumes 4 times more power than that for IPv4.
>
> However, as global routing table size of IPv6 is a lot smaller
> than that of IPv4, the number of the entries of TCAM for IPv6
> is a lot smaller than that for IPv4. But it is so primarily
> because IPv6 is not very widely deployed.

Uh, no. It is so because on average IPv4 is so fragmented that most
providers of any size are advertising 8+ prefixes compared to a more
realistic IPv6 average of 1-3.

Owen

On 11/19/2021 1:27 PM, William Herrin wrote:
> On Fri, Nov 19, 2021 at 10:22 AM Zu <mu@zuqq.me> 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

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 <ml@kenweb.org> wrote:
>
> ?
>
>> On 11/19/2021 1:27 PM, William Herrin wrote:
>>> On Fri, Nov 19, 2021 at 10:22 AM Zu <mu@zuqq.me> 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

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

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 - jay@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

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

On Sat, 20 Nov 2021 at 09:38, John Lee <jllee9753@gmail.com> wrote:

> Cisco and Juniper routers have had v6 functionality for over 10 years. Lucent/Nokia, and others. Check UNL list at
> https://www.iol.unh.edu/registry/usgv6 for v6 compliant routers and switches.

People who work with network devices directly using other APIs than
email. phone and slack know that feature parity to this day is not
there. And know that IPv6 is a massive time commitment, more than
doubling many of the work involved in testing, automating,
provisioning and operating.
I could explain a lot about the relative merits of IPv4 and IPv6
design and how well those design choices map to silicon or benefit
users, but I don't anymore care how bad/good IPv4 and IPv6 are
relative to each other, I'm just tired of the dual stack suck and how
much it steals from me and my users. And how we, the IP engineer
community have failed our customers in this transition. We cocked up,
it happened on our watch.

--
++ytti

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 <https://bgp.potaroo.net/> 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

On Sat, Nov 20, 2021 at 6:27 PM Joe Maimon <jmaimon@jmaimon.com> 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