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.

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

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

Owen DeLong wrote:

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

Mergers of entities having an IP address range is a primary reason
of entities having multiple address ranges. As IPv6 was
developed a lot later than IPv4, it has not suffered from
mergers so much yet.

Masataka Ohta

Subject: Re: is ipv6 fast, was silly Redeploying Date: Mon, Nov 22, 2021 at 02:04:55AM +0900 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.jp):

> Mergers of entities having an IP address range is a primary reason
> of entities having multiple address ranges. As IPv6 was
> developed a lot later than IPv4, it has not suffered from
> mergers so much yet.

Yes. You are completely correct. But, those entities usually have
one v6 prefix each. And multiple v4 ones. Because they've required
more addresses. Not everyone are Apple, "hp"[0] or MIT, where initial
allocation still is mostly sufficient. (I believe MIT handed some back
too) Instead they had to ask repeated times for smaller and smaller
chunks of addresses. (Now they're buying them for prices that may well
be motivating people to come up with crazy schemes of reusing reserved
addresses.. )

In contrast, the v6 allocations are mostly sufficient. Even for sprawling
businesses. In the end, if they merge with another company, each merger
brings one (1) more net, not a flock of v4 /24's.

Your reasoning is correct, but the size of the math matters more.
--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
Content: 80% POLYESTER, 20% DACRONi ... The waitress's UNIFORM sheds
TARTAR SAUCE like an 8" by 10" GLOSSY ...

[0] The real Hewlett-Packard made test equipment. What calls itself "hp"
today is just another IT company.

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

On November 20, 2021 at 21:29 jay@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 | 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*

> On Nov 21, 2021, at 09:04 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> Owen DeLong wrote:
>
>> 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.
>
> Mergers of entities having an IP address range is a primary reason
> of entities having multiple address ranges. As IPv6 was
> developed a lot later than IPv4, it has not suffered from
> mergers so much yet.

No, it is not. Slow start and other RIR policies around scarcity and fairness of
distribution of the last crumbs are the primary contributor, with traffic engineering
a somewhat distant second. Mergers are actually somewhere around 10th on the list last
time I looked.

Owen

Mans Nilsson wrote:

> Not everyone are Apple, "hp"[0] or MIT, where initial
> allocation still is mostly sufficient.

The number of routing table entries is growing exponentially,
not because of increase of the number of ISPs, but because of
multihoming.

As such, if entities requiring IPv4 multihoming will also
require IPv6 multihoming, the numbers of routing table
entries will be same.

The proper solution is to have end to end multihoming:

https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt

> Your reasoning is correct, but the size of the math matters more.

Indeed, with the current operational practice. global IPv4
routing table size is bounded below 16M. OTOH, that for
IPv6 is unbounded.

Masataka Ohta

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

> On Nov 22, 2021, at 02:45 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> Mans Nilsson wrote:
>
> > Not everyone are Apple, "hp"[0] or MIT, where initial
> > allocation still is mostly sufficient.
>
> The number of routing table entries is growing exponentially,
> not because of increase of the number of ISPs, but because of
> multihoming.

Again, wrong. The number is growing exponentially primarily because of the
fragmentation that comes from recycling addresses.

> As such, if entities requiring IPv4 multihoming will also
> require IPv6 multihoming, the numbers of routing table
> entries will be same.

There are actually ways to do IPv6 multihoming that don’t require using the
same prefix with both providers. Yes, there are tradeoffs, but these mechanisms
aren’t even practical in IPv4, but have been sufficiently widely implemented in
IPv6 to say that they are viable in some cases.

Nonetheless, multihoming isn’t creating 8-16 prefixes per ASN. Fragmentation
is.

>> Your reasoning is correct, but the size of the math matters more.
>
> Indeed, with the current operational practice. global IPv4
> routing table size is bounded below 16M. OTOH, that for
> IPv6 is unbounded.

Only by virtue of the lack of addresses available in IPv4. The other tradeoffs
associated with that limitation are rather unpalatable at best.

Owen

Owen DeLong wrote:

>> The number of routing table entries is growing exponentially, not
>> because of increase of the number of ISPs, but because of
>> multihoming.
>
> Again, wrong. The number is growing exponentially primarily because
> of the fragmentation that comes from recycling addresses.

Such fragmentation only occurs when address ranges are rent to
others for multihoming but later recycled for internal use,
which means it is caused by multihoming.

Anyway, such cases are quite unlikely and negligible.

> There are actually ways to do IPv6 multihoming that don’t require
> using the same prefix with both providers.

That's what I proposed 20 years ago both with IPv4 and IPv6 in:

https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt

> Yes, there are tradeoffs,
> but these mechanisms aren't even practical in IPv4,

Wrong. As is specified by rfc2821:

When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. However, there MAY also be a configurable

the idea of end to end multihoming is widely deployed by SMTP at
the application layer, though wider deployment require TCP
modification as I wrote in my draft.

Similar specification is also found in section 7.2 of rfc1035.

> but have been
> sufficiently widely implemented in IPv6 to say that they are viable
> in some cases.

You are just wrong. IP layer has very little to do with it.

Masataka Ohta

PS

LISP is garbage.

> On Nov 23, 2021, at 12:28 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
>
> Owen DeLong wrote:
>
>>> The number of routing table entries is growing exponentially, not
>>> because of increase of the number of ISPs, but because of multihoming.
>> Again, wrong. The number is growing exponentially primarily because
>> of the fragmentation that comes from recycling addresses.
>
> Such fragmentation only occurs when address ranges are rent to
> others for multihoming but later recycled for internal use,
> which means it is caused by multihoming.

Nope… It occurs when (e.g. HP or MIT or AMPR) sell off pieces of a class A
as smaller prefixes to various other purchasers.

It happens when /16s are sold off to multiple purchasers in pieces.

> Anyway, such cases are quite unlikely and negligible.

ROFLMAO you are demonstrating your extreme detachment from reality:

http://ipv4marketgroup.com <http://ipv4marketgroup.com/>
http://ipv4auctions.com <http://ipv4auctions.com/>
etc.

There are multiple businesses that do almost nothing outside of these types of transactions.

>> There are actually ways to do IPv6 multihoming that don’t require
>> using the same prefix with both providers.
>
> That's what I proposed 20 years ago both with IPv4 and IPv6 in:
>
> https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt

THat’s not one of the alternatives I was talking about.

>> Yes, there are tradeoffs,
>> but these mechanisms aren't even practical in IPv4,
>
> Wrong. As is specified by rfc2821:
>
> When the lookup succeeds, the mapping can result in a list of
> alternative delivery addresses rather than a single address, because
> of multiple MX records, multihoming, or both. To provide reliable
> mail transmission, the SMTP client MUST be able to try (and retry)
> each of the relevant addresses in this list in order, until a
> delivery attempt succeeds. However, there MAY also be a configurable
>
> the idea of end to end multihoming is widely deployed by SMTP at
> the application layer, though wider deployment require TCP
> modification as I wrote in my draft.

Again, NOT what I was talking about. I was talking about the fact that in IPv6, you can multi-home by applying a prefix from each provider to each subnet. If the upstream connection goes away, deprecate the RA for that prefix and/or mark it as no longer on-link.

> Similar specification is also found in section 7.2 of rfc1035.

You are talking about pomegranate seeds, I’m talking about Apples. They are not the same, so your statements about my remarks are inherently flawed.

>> but have been
>> sufficiently widely implemented in IPv6 to say that they are viable
>> in some cases.
>
> You are just wrong. IP layer has very little to do with it.

No, you’re just talking about a form of multihoming that has absolutely nothing to do with the forms I was referring to.

> LISP is garbage.

Somewhat agree, though the concept wasn’t entirely wrong. Separating Locators from IDs is something we will eventually need to do in order to scale internet routing. LISP is definitely
not the ideal way to do it, but was a valiant attempt if one assumes the constraints of having to operate in an existing IPv6 environment. If one is willing to modify the packet header, then there are better options.

Owen

When considering the IPv6 product, I would suggest you read
USGv6-Revision-1 (1) to define the specification you need for the product.
Then go to the USGv6 Registry (2), select the features and read the
Supplier Declaration of Conformity (SDOC) to ensure that the product meets
your requirements. Do this prior to having the discussion with the vendor
sales.

Also, ask for documents which provide details on performance and security
testing. It will save you hours of troubleshooting problems and patching
vulnerability.

Lessons learned from implementing IPv6 products.

(1) https://www.nist.gov/programs-projects/usgv6-program/usgv6-revision-1
(2) https://www.iol.unh.edu/registry/usgv6

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
"*I skate to where the puck is going to be, not to where it has been."
-- *Wayne
Gretzky
"I never lose. I either win or learn" - Nelson Mandela


On Sat, Nov 20, 2021 at 2:36 AM 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.
>
> 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
>>
>

Owen DeLong wrote:

>>> Again, wrong. The number is growing exponentially primarily
>>> because of the fragmentation that comes from recycling
>>> addresses.

> Nope… It occurs when (e.g. HP or MIT or AMPR) sell off pieces of a
> class A as smaller prefixes to various other purchasers.

That, by no means, is not recycling. Moreover, most, if not
all, entities purchasing address ranges use them with multihoming.

> ROFLMAO you are demonstrating your extreme detachment from reality:

So, you have never thought about the reason why people buy
IP addresses.

>> https://tools.ietf.org/id/draft-ohta-e2e-multihoming-02.txt
>
> THat's not one of the alternatives I was talking about.

That you haven't mentioned any alternative and have talked
about nothing is your problem.

Masataka Ohta

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 jared@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On Thu, Nov 25, 2021 at 8:25 AM Jared Mauch <jared@puck.nether.net> 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 jared@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