nanog mailing list archives
Re: 202401100645.AYC Re: IPv4 address block
From: Matthew Petach <mpetach () netflight com>
Date: Fri, 12 Jan 2024 16:27:26 -0800
On Fri, Jan 12, 2024 at 2:43 AM Nick Hilliard <nick () foobar org> wrote:
Matthew Petach wrote on 11/01/2024 21:05:I think that's a bit of an unfair categorization--we can't look at pre-exhaustion demand numbers and extrapolate to post-exhaustion allocations, given the difference in allocation policies pre-exhaustion versus post-exhaustion.Matt, the demand for publicly-routable ipv4 addresses would be comparable to before, with the additional pressure of several years of pent-up demand. You're right to say that allocation policies could be different, but we had discussions about run-out policies in each RIR area in the late 2000s and each RIR community settled on particular sets of policies. I don't see that if an additional set of ipv4 address blocks were to fall out of the sky, that any future run-out policies would be much different to what we had before. So 240/4 might last a month, or a year, or two, or be different in each RIR service area, but it's not going to change anything fundamental here, or permanently move the dial: ipv4 will still be a scarce resource afterwards. Nick
Hi Nick, I participated in many of those pre-exhaustion policy discussions at ARIN meetings; at the time, I thought a hard landing would motivate everyone to simply shift to IPv6. Having lived through the free-pool exhaustion, and discovered that the hard landing concept didn't get people to move to IPv6, it just made the battle for IPv4 resources more cutthroat, I've come to rethink my earlier stances on NRPM updates. I suspect I'm not the only one who sees things differently now, in a post-exhaustion world with no signs of IPv6 adoption crossing the nebulous tipping point any time soon. In light of that, I strongly suspect that a second go-around at developing more beneficial post-exhaustion policies might turn out very differently than it did when many of us were naively thinking we understood how people would behave in a post-exhaustion world. If we limit every registrant to only what is necessary to support the minimum level of NAT'd connectivity for IPv4, we can stretch 240/4 out for decades to come. You don't need a *lot* of IPv4 space to run 464XLAT, for example, but you *do* need at least a small block of public IPv4 addresses to make the whole thing work. If you limit each requesting organization to a /22 per year, we can keep the internet mostly functional for decades to come, well past the point where L*o has retired, and Android starts supporting DHCPv6. ;) But I agree--if we looked at 2000's era policies, 240/4 wouldn't last long. I just think that many of us have matured a bit since then, and would vote differently on updates to the NRPM. ^_^ Thanks! Matt
Current thread:
- Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block, (continued)
- Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block Randy Bush (Jan 12)
- Re: IPv4 address block Nick Hilliard (Jan 11)
- Reusable 240/4 Re: IPv4 address block Abraham Y. Chen (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Gaurav Kansal via NANOG (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Tom Beecher (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Dave Taht (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Tom Beecher (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Matthew Petach (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Owen DeLong via NANOG (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Nick Hilliard (Jan 12)
- Re: 202401100645.AYC Re: IPv4 address block Matthew Petach (Jan 12)
- Re: IPv4 address block Nick Hilliard (Jan 13)
- Re: IPv4 address block Christopher Hawker (Jan 13)
- Re: IPv4 address block Randy Bush (Jan 13)
- Re: 202401100645.AYC Re: IPv4 address block Brandon Butterworth (Jan 12)
- Re: 202401100645.AYC Re: IPv4 address block Christopher Hawker (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Owen DeLong via NANOG (Jan 11)
- Burn Rate? Re: 202401100645.AYC Re: IPv4 address block Abraham Y. Chen (Jan 12)
- Re: Burn Rate? Re: 202401100645.AYC Re: IPv4 address block Niels Bakker (Jan 12)
- Re: Burn Rate? Re: 202401100645.AYC Re: IPv4 address block Abraham Y. Chen (Jan 13)
- Re: Burn Rate? Re: 202401100645.AYC Re: IPv4 address block Niels Bakker (Jan 13)