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

On Thu, Nov 25, 2021 at 8:25 AM Jared Mauch wrote: > > On Fri, Nov 19, 2021 at 09:43:26AM -0800, Michael Thomas wrote: > > > > On 11/19/21 8:27 AM, Randy Bush wrote: > > > these measurements would be great if there could be a full research- > > > style paper, with methodology artifacts, and

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

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

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

On Thu, Nov 18, 2021 at 1:21 PM John Gilmore wrote: > We have found no ASIC IP implementations that > hardwire in assumptions about specific IP address ranges. If you know > of any, please let us know, otherwise, let's let that strawman rest. > There's at least one. Marvell PresteriaCX (its

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

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

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

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

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

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

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

On Sat, Nov 20, 2021 at 6:27 PM Joe Maimon wrote: > Tom Beecher wrote: > [...] > > > > IPv6 isn't perfect. That's not an excuse to ignore it and invest the > > limited resources we have into Yet Another IPv4 Zombification Effort. > > > As noted earlier, False Dilemma > > Even worse, your

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

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

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

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

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

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

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

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

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

That fine. XP supports IPv6 and apart from the DNS needing a IPv4 recursive server it works fine. -- Mark Andrews > On 21 Nov 2021, at 11:23, ML wrote: > >  > >> On 11/19/2021 1:27 PM, William Herrin wrote: >>> On Fri, Nov 19, 2021 at 10:22 AM Zu wrote: >>> One anecdote (the

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

On 11/19/2021 1:27 PM, William Herrin wrote: On Fri, Nov 19, 2021 at 10:22 AM Zu wrote: One anecdote (the non-technical grandma) illustrates a very real problem that would need to be addressed -- there are non-technical people (of all ages, if your concerned about ageism) which will need

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

> On 20-Nov-2021, at 02:21, g...@toad.com wrote: > > David Conrad wrote: >> Doesn't this presume the redeployed addresses would be allocated >> via a market rather than via the RIRs? >> >> If so, who would receive the money? > > You ask great questions. > > The community can and should do

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

> On Nov 19, 2021, at 12:11 , Jim wrote: > > On Thu, Nov 18, 2021 at 8:24 PM David Conrad wrote: >> > ... >> Some (not me) might argue it could (further) hamper IPv6 deployment by >> diverting limited resources. > > It may help IPv6 deployment if more V4 addresses are eventually >

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

> On Nov 19, 2021, at 11:46 , John Gilmore wrote: > > Joe Maimon wrote: >> And all thats needed to be done is to drop this ridiculous .0 for >> broadcast compatibility from standards.why is this even controversial? > > Not to put words in his mouth, but that's how original BSD

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

> On Nov 19, 2021, at 10:22 , John Curran wrote: > > On 18 Nov 2021, at 8:14 PM, b...@theworld.com > wrote: >> That suggests an idea: >> >> Repurpose these addresses and allow the RIRs to sell them in the IPv4 >> secondary markets with some earmark for the funds.

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

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

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

David Conrad wrote: > Doesn't this presume the redeployed addresses would be allocated > via a market rather than via the RIRs? > > If so, who would receive the money? You ask great questions. The community can and should do the engineering to extend the IP implementations. If that doesn't

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

Fred Baker wrote: > I tend to think that if we can somehow bless a prefix and make be > global unicast address space, it needs to become Global Unicast > Address Space. Yes, I agree. The intention is that with the passage of time, each prefix becomes more and more reachable, til it's as close

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

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

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

On Thu, Nov 18, 2021 at 8:24 PM David Conrad wrote: > ... > Some (not me) might argue it could (further) hamper IPv6 deployment by > diverting limited resources. It may help IPv6 deployment if more V4 addresses are eventually released and allocated Assuming the RIRs would ultimately like to

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

Joe Maimon wrote: > And all thats needed to be done is to drop this ridiculous .0 for > broadcast compatibility from standards.why is this even controversial? Not to put words in his mouth, but that's how original BSD maintainer Mike Karels seemed to feel when we raised this issue for

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

On 11/19/21 10:15 AM, William Herrin wrote: On Fri, Nov 19, 2021 at 10:04 AM Michael Thomas wrote: I don't think you can overstate how ASIC's made changing anything pretty much impossible. It's why all of the pissing and moaning about what ipv6 looked like completely missed the point. There

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

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

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

On Fri, Nov 19, 2021 at 10:32 AM John Curran wrote: > There’s this organization called the Internet Engineering Task Force that has > been working hard to establish long-term financial independence and stability > via the IETF Endowment project – > > Several of

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

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

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

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

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

On Fri, Nov 19, 2021 at 10:04 AM Michael Thomas wrote: > I don't think you can overstate how ASIC's made changing anything pretty > much impossible. > It's why all of the pissing and moaning about what ipv6 looked like > completely missed the point. There was a fuse lit in 1992 to when the >

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

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

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

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

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

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

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

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

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

> On Nov 18, 2021, at 12:54 , John Gilmore wrote: > > Steven Bakker wrote: >> The ask is to update every ip stack in the world (including validation, >> equipment retirement, reconfiguration, etc)... > > This raises a great question. > > Is it even *doable*? What's the *risk*? What will

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

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

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

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

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

On Thu, Nov 18, 2021 at 11:37:49AM -0800, John Gilmore wrote: > Steven Bakker wrote: > > > ... the gain is 4 weeks of > > > extra ip address space in terms of estimated consumption. > > > > The burn rate is the best argument I've seen against the idea so far. > > I'm glad you think so, since

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

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

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

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 -

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

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

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

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

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

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

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

John, On Nov 18, 2021, at 12:54 PM, John Gilmore wrote: > Is it even *doable*? With enough thrust, pigs fly quite well, although the landing can be messy. > What's the *risk*? Some (not me) might argue it could (further) hamper IPv6 deployment by diverting limited resources. > What will it

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

Sent using a machine that autocorrects in interesting ways... > On Nov 18, 2021, at 5:15 PM, John Gilmore wrote: > > Keeping the price of IPv4 addresses reasonable means that dual-stack > servers can continue to be deployed at reasonable cost, so that it > doesn't matter whether clients have

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

Randy Bush wrote: > as a measurement kinda person, i wonder if anyone has looked at how much > progress has been made on getting hard coded dependencies on D, E, 127, > ... out of the firmware in all networked devices. The drafts each have an Implementation Status section that describes what we

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

John, On Nov 18, 2021, at 11:37 AM, John Gilmore wrote: > At current rates, 300 to 400 million addresses would last more than a decade! Doesn’t this presume the redeployed addresses would be allocated via a market rather than via the RIRs? If so, who would receive the money? > There will be

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

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

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

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

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

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

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

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

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

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

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

Steven Bakker wrote: > The ask is to update every ip stack in the world (including validation, > equipment retirement, reconfiguration, etc)... This raises a great question. Is it even *doable*? What's the *risk*? What will it *cost* to upgrade every node on the Internet? And *how long*

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

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