Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login
250M-plus reserved IPv4 addresses could be released (www.theregister.com) similar stories update story
61 points by fariszr | karma 1464 | avg karma 5.55 2024-02-09 16:11:41 | hide | past | favorite | 111 comments



view as:

If they are, I kinda hope that I could get my hands on one. Or a few.

It’s not going to happen. Plenty of routers and other equipment are hardcoded to not route to those addresses. Any time spent rectifying this is time wasted on just adopting IPv6.

Ping 240.whatever.whatever.whatever from Windows. You just can’t. General failure.

And Windows is not the exception here.

They can lobby all they want, all the effort is going to be in vain. Imagine having to debug a problem where your services are sitting on 240.0.0.0/4, but some customers have routers that just drop the packets to that destination. It’d be a nightmare and “get better networking gear” might not even be a solution, because their ISPs routers could also be doing that.

This proposal is provably worse than just adopting IPv6, because when IPv6 works, it just works. This? This would fragment the IPv4 internet with undefined behaviour.

If they really want more v4 space, they should advocate for yoinking the v4 space that e.g. the DoD, Daimler, Ford or Apple doesn’t use. And they have a lot of v4 space. But that’s also not going to happen, and one of the reasons why not would be similar. A lot of people are actually squatting on DoD space in their internal networks if they run out of 10/8.


[flagged]

Like clockwork this comment shows up...

Often it's even the same users, as if all the reasons it wouldn't work were't explained to them the last times they reflexively suggested it at the mention of IPv6:

https://news.ycombinator.com/item?id=39100317

https://news.ycombinator.com/item?id=36996003

https://news.ycombinator.com/item?id=35047061

...


Can you explain exactly how a IPv4 host would send packet to 1.2.4.5.6. What fields inside a fixed IP packet it would set to achieve such?

> Make them all inter-compatible and backward-compatible by modifying the packet structure to accept a variable length address.

"Simply draw the rest of the Owl".


And a real IPv6 (128 bit) address would look like 164.32.74.105.164.32.74.105.164.32.74.105.164.32.74.105

By that logic, ipv6 would be 1.2.3.4.1.2.3.4.1.2.3.4.1.2.3.4

Easy to remember, indeed


Address with patterns are indeed easy to remember, see how easy 1:2:3:4:: is to remember. So all we have to do is allocate everyone an artisanally crafted address with easy to remember patterns /s

Have you heard of domain names? They can be very memorable!

- 8.8.8.8 is IPv4 google DNS

- What is IPv6 google DNS? Hell if I can remember it. 2001:4680:something?

Guess which one is going into the DNS config of a new machine that I have to bring up and am forced to deliver results on short notice.


It's Google's prefix (`2001:4860:4860`) with `8888` and `8844` on the end.

If you can't remember that, the problem's not the protocol.


And why on earth would you remember 8.8.8.8 in the first place ?

For almost all the thing, I use DNS For DNS resolvers, I use root servers

Never shall I use 8.8.8.8 : why would I ..


You post a strawman IPv6 address to HN every month or so. Why not take a minute to learn what a real address looks like?

For example, 2eff:ff:a0ee::/54 is a prefix and 2eff:ff:a0ee::dead:beef is an address within that prefix. It is invalid for "::" to appear more than once, as that would be ambiguous.


Because nobody has fixed the bad UX yet, I'm still on IPv4, and like 5 million other people, have no incentive to move to IPv6 until the consortium of PMs of IPv6 do some user research (e.g. read HN) and work together to make the UX better or invent a better successor that people actually want to use.

They're all wondering why IPv6 adoption is so slow, I'm telling them right here plain and simple.


You're trying to close the door after the horse has left the barn and started a worldwide colony of horsepeople.

IPv6 isn't perfect, but it's not really practical to change the fundamentals of a 25 year old protocol.


> problem where your services are sitting on 240.0.0.0/4, but some customers have routers that just drop the packets to that destination.

On the other hand, as an ISP, you can pull some of those addresses for your CGNAT's external address pool. Your customers' gear will never see those. Server side will, though. But then, troubleshooting cloud/server front-end to reliably let those through sounds like a more doable chore?


You can still connect to other non-nated individuals that might not expect that.

> On the other hand, as an ISP, you can pull some of those addresses for your CGNAT's external address pool.

You're right but ugh, CGNAT. We just had fiber deployed here (yay!) and then I got assigned an ISP that has me behind CGNAT. The list of things that can make icky Spectrum better than fiber (for me) is super short, but CGNAT in the 1 or 2 spot.


CGNAT will become common for residential IPv4, because math.

It's more reasonable to expect ISPs to provide native IPv6 alongside CGNAT, than avoid CGNAT entirely.


> It's more reasonable to expect ISPs to provide native IPv6 alongside CGNAT, than avoid CGNAT entirely.

You'd think so but of our fiber ISPs, 0 of 8 support IPv6 or have plans to do so - inc the NATty ones.


Well, expectations do not always match reality.

I suggest that you complain about their lack of IPv6, and encourage other customers to do the same.


> CGNAT will become common for residential IPv4, because math.

Oh and thanks for inserting this dystopic hellscape into my awareness, btw. I hope you're wrong for a long time.


...and about that part:

> advocate for yoinking the v4 space that e.g. the DoD, Daimler, Ford or Apple doesn’t use

Isn't it a travesty that owning a sizeable chunk of limited-supply IP addresses doesn't cost much, but exact same number of (nearly-)unlimited-supply domains does cost dearly per-domain to own?

We don't hear horror stories how somebody is hoarding 16 millions .com domains, right? Too expensive to do so.


We do. With gTLDs they can hoard all the domains under there... And price them how they like.

Then again, we can generate nearly infinite amount of gTLDs so it is not too big deal.


I am bugged that the BEAD programs do not seem to grok that we are indeed out of IPv4 space, and that the federal government is sitting on 10? 11 idle /8s.

All OpenWRT based routers have supported it for a very long time now.

Also note the proposal is for 240/4 to be added to the RFC1918 list, not to be globally routable.

I’ve been using 240/4 successfully in internal networks for over a decade now. The only devices I’ve had problems with are Windows. So for a quick win, Windows just needs to drop special checks they do for 240/4.

I recall the 240/4 idea being floated at least 5-10 years ago. If Windows was changed to allow it at that point, today hardly anyone would be complaining that Ciscos or Junipers or other core routers don’t support it.

Don’t let perfect be the enemy of good.


Why do we need more RFC1918 addresses? What's wrong with 10.0.0.0/8?

Some larger companies need it. I say if their equipment supports it and it's currently unused globally, then let it work internally.

Fair enough.

This proposal is not regarding repurposing 240/4 as RFC1918 space. It is regarding reclassifying it as Unicast space. I would recommend reading the article.

My bad. I was replying to the parent comment but you're right that I should have read the article.

> If Windows was changed to allow it at that point, today hardly anyone would be complaining that Ciscos or Junipers or other core routers don’t support it.

Yes. But it wasn’t. Making this proposal a day late and a dollar short.


Well, I would put a dollar on this proposal being made again and again over the years to come. It’s still not too late.

> So for a quick win, Windows just needs to drop special checks they do for 240/4.

Notging special because it's actually in the routing table, as it should be.

Issue ROUTE PRINT to see it yourself.


Haven’t checked in a couple years, but can you assign a 240.0.0.1/24 for example to the local NIC on Windows?

Assigning is another deal (tested on 2012R2):

    netsh interface ipv4>add add "4084" 200.0.0.1 255.255.255.0

    netsh interface ipv4>add add "4084" 240.0.0.1 255.255.255.0
    The parameter is incorrect.

    netsh interface ipv4>sh add 4084

    Configuration for interface "4084"
        DHCP enabled:                         No
        IP Address:                           200.0.0.1
        Subnet Prefix:                        200.0.0.0/24 (mask 255.255.255.0)
        InterfaceMetric:                      10
The GUI interface explicitly tells to use 'from 1 to 223' for the first octet.

If its just about internal networks then just use a nonrouteable IP. Its not like there are a shortage addresses in the 10.0.0.0/8 network. That is almost 17 million addresses you can do anything with. Somehow if you do run out then just add an extra router and suddenly you have another almost 17 million addresses.

"just add an extra router".

I think when conceiving of potential issues with this, or thinking about the possible problems of trying to merge two overlapping networks together, your imagination is coming up a little short.

It's never that simple.


The networks could not overlap if the given range does not route. Anyways, that misses the point as the challenges of configuring the corresponding routing table would be trivial compared to managing 16 million devices on a single internal network.

I’ve worked with large organisations that have merged dozens of companies networks. There were lots of clashes.

I’ve also worked with companies where their networks filled up almost all the 10/8 space and they were running out of room. Having to do things like shrink subnets at individual locations and deal with issues around not able to install all the equipment they originally wanted. It’s a real pain.

And yes, the entire 10/8 space needed to be routable through to the corporate support desk, SIEM tools, payment systems, loyalty systems, security and other IoT systems, etc.

Yes sure you could probably NAT things, or switch to tools/approaches that don’t require every device to have an internally routable IP, but then that’s a terrible argument akin to arguments against IPv6.


There are several proposals. The most current one merely advocates that 240/4 be moved from reserved for future use to unicast status, which is the deployed reality today.

I hate the idea of wasting 6% of the original internet on rfc1918 space.


Given it is already used internally, it cannot be used as public space. The only practical option for it is RFC1918.

If people are using space that has been marked as "Reserved For Future Use" within their networks, then this is a problem that they must deal with and it must not affect or influence global usage. What about networks squatting on DoD /8 space? Does this mean the DoD can never route this space publicly because people are using it internally?

DoD space /8 is different as it is within the public space of IPv4, even if it was never advertised globally.

Whereas 240/4 was never declared public.

Apples and Oranges.


You are correct, 240/4 was never marked as public space, it was marked as Reserved for Future Use. Network operators squatting on 240/4 space should have never done so as it was not decided as to what it was going to be used for, hence its current status.

Like I said, if people squat on reserved space and the status changes, that's too bad for them if it's reallocated and made routable. Network operators have no right to dictate that space cannot be made routable, simply because they are using space internally and against current policies.


Our proposal isn't for 240/4 to be reclassified as RFC1918 space, it's for it to be reclassified as unicast space.

And here I was excited, me, as a common person, could possibly buy a block of ipv4. Dream crusher.

I wish I had enough clout - as jon postel did - to merely declare I was the authority on 255/8 and was selling /24s at an auction price to anyone that was willing to route it. I´d use the money to support open source, and to help fund the rest of the ipv6 transition. And buy myself a nice sailboat to sail around in whilst I de-bufferbloated the rest of the networks of the world.

240/4 for windows is a patch tuesday away.

This again? Just use v6, it’s not that hard.

Judging by the amount of infrastructure that doesn't yet support IPv6 (even parts of AWS), it seems to be harder than "easy" at least.

From a consumer standpoint, I wish it was.

I cannot tell you how many devices or software have had a notice of "just disable IPV6, that will fix X" and it's worked perfectly.

If V6 was working everywhere and it was a simple toggle I'd say sure. But it's not.


> I cannot tell you how many devices or software have had a notice of "just disable IPV6, that will fix X" and it's worked perfectly.

I’ve heard this advice dozens of times, but it hasn’t worked once, to the point where I firmly believe that everyone giving out such advice either completely doesn’t care or know anything about networking, or, is suffering from some sort of a mental difficulty.


Eh, I disagree. There are ton of crappy consumer grade devices that claim to support IPv6 but there are obscure implementation issues and these same devices offer zero visibility into what the cause might be. Sure, a packet sniffer might explain some of it but the remedy may require adjustment to the device which abstracts all the IP config away. The situation sucks all around.

> Eh, I disagree. There are ton of crappy consumer grade devices

I support all kinds of devices and turning off IPv6 was sometimes a thing I did. No so much now. Maybe once in the last 5 years.


This is generally caused by ignorance. Don't understand IPv6 so turn it off without investigating what the actual problem is. Usually it's caused by a broken IPv6 configuration - eg a route being announced but no actual connectivity.

Here IPv6 works perfectly and doesn't cause any problems. Many sites are much faster over v6 than legacy IP. Google stats show 45% of users access google over IPv6 so clearly it's working for all those millions of users too.

If IPv6 is not working you need to fix it, not turn it off.


As I understand this proposal is not for consumers. So any talks about 'we need that instead pf ipv6' is desingenuous at best.

Also no consumer can be at limit pf rfc1918 even if throwing /24 right and left.


That’s just the natural consequence of running two protocols simultaneously.

People get issues with v4. But “just switch off v4” is never suggested as a solution cos it’s either all people have or they need it for the sites that only have it. So people fix problems they get with v4. If they get a problem with v6? Switch it off, v4 is working.

Granted v6 has had many teething problems and still isn’t as hassle-free as v4. But in recent years things have improved an awful lot.


I would use IPv6 but my ISP doesn't support it. :-)

My ISPs lack of support for IPv6 got me into BGP.

I now run my own ASN, rent a server with a BGP session that’s pretty close to my home (~50km/2ms), and tunnel v6 over that.

I have a /32 of v6. That’s 2^96 individual addresses. Or 65k /48s.

It was a great learning experience actually and is within the reach of anyone. You can get a BGP enabled VPS for $5/month, and ASN and a /40 for $50/lifetime.


I’d love to see a write-up of how you did this! It’s been on my bucket list for a while.

You can also get a tunnel going through https://tunnelbroker.net/. I use this with my PFsense gateway.

You got some hints for how/where to get that ASN and /40?

When I looked into this I only found relatively expensive options.


Once you've been allocated your ASN and /32 subnet, is there any requirement that they continue to be used, or is it ok to sit on it for later use too?

My IP space is PA, it’s allocated by a LIR.

RIPE does have a requirement that you use your ASN, and that it’s multihomed.

Multihoming rule isn’t enforced (meaning a single upstream is fine), but they do require you to actually use it.


I find it mildly horrifying that they hand out /32s.

There can be as many /32s in IPv6 as devices on the IPv4 internet.

RIPE hands out a /29 to any member without any requirements. For anything beyond a /29 you need to prove that you actually need it, but /29s they hand out like candies. As a LIR you can then lease out /32s. And when you run out of space to lease, request more space.

I know a guy with 15x /29s.

I actually find this scary too, but I mean, it’s /29s, not /8s.


It is quite expensive to be a full member of RIPE though. Most people with smaller requirements can go through a sponsoring LIR to get PI space (like a /48).

Which RIR? I think you have a typo on that price

RIPE, via a LIR, but it doesn’t matter, because ASNs are end-user resources. IP space is all PA though.

The /32 I’m renting however.


Ah the dollar sign made me think you were in ARIN, and they used to charge $550 for new ASNs

You can get an ASN and IP space from RIPE (or a RIPE LIR) even if you’re in ARIN area geographically.

All you need is proof of network presence within RIPE region (and yes, a $5/mo BGP VPS from Vultr satisfies that requirement). Then you can announce your RIPE v6 wherever you want.


Could you please explain how to get an ASN and a /40 for $50/lifetime? I only know the option where you pay a yearly fee.

The guy I got my ASN no longer files them, but this guy also comes highly recommended.

https://ifog.ch/en/ip/lir-services

CHF 60/lifetime for natural persons , which is about $60.

The guy that did my ASNs still does IP space - https://my.cloudie.sh/index.php?rp=/store/lir-services

$10/y for a /40.

A bit more expensive than the $50/lifetime that I promised, but that was the deal I got from Cloudie.


I got a /44 for a small price(It was free, but I payed for it). No ASN.

Announced one /48 over AWS and tunneled to it to browse the internet via my own IPv6. It works fine.


> You can get a BGP enabled VPS for $5/month

Honestly, where do I get that ?


Tell that to AWS

Turkey, with 85m population and 75% internet users, has less than 3% IPv6 adoption.

National adoption rates of IPv6 is often more determined by historical IPv4 allocations and decisions of a number of sysadmins in the 100s at consumer facing ISPs, not a factor of the population's size

Of course not. I mentioned population to point at how big a market Turkey is, which makes the whole "just switch to IPv6" more problematic than it seems. We just can't do it at once, so IPv4 is going to be around for the foreseeable future. I mean, unless we create a service that is IPv6 only to create public pressure.

Like, what if TikTok was IPv6 only? We would have 100% IPv6 by now.


Let's remember who the audience for this article is. It is not for consumers or application developers.

It's for network operators (and equipment vendors). Telling network operators "Let's just switch to V6" is not in anyway problematic. If every network operator decided to make it a priority we could have 90% of internet customers on v6 enable networks within 2 years. Easily.

Of course SaaS/Content providers need to run dual stack for a while. But ISPs need to stop dragging their damn feet and deploy v6.


> But ISPs need to stop dragging their damn feet...

But, why would they if dragging their feet makes them a lot of money? Why would they bother unless there's massive demand from the public for full IPv6 adoption?

I mean even ISPs with IPv6 support don't care about the IPv6 experience of their customers. AT&T, for example, doesn't give more than a /64 address space to home users, which only supports one subnet. If you have, say, a guest network and a trusted network, you can't have separate inbound routing/firewall rules as both would have the same prefix.

So, I disagree that convincing network operators is the right way to go about it. We need to convince the public about the benefits of IPv6.


It took me 6 hours to configure a Ubiquiti Edge Router to properly request an IPv6 prefix because of how poor the IPv6 support is right now. And by default the firewall is completely permissive because the web UI doesn't have support for IPv6.

And the prefix I get is dynamic. It changes each time the router power cycles or has a brownout or if the upstream network restarts for whatever reason (which is something I saw happening with regularlity on a different ISP about 1am to 2am, presumably them performing maintenance). So that means my firewall rules have to be constantly monitored and changed if they're any more complicated then reject all incoming connections. Only way I can see that working right now is to write a daemon that can hook into the PD process for that.

Plus how do I get my servers that are supposed to be internet facing to update their IPv6 prefix every time it changes? Does that mean that I have to put in additional code in every server to update their IPv6 addresses every single time the prefix is changed?

Oh and I can request a /54 no problem for now. There's no guarantee for instance if ISP decides to restrict residential users to only a /64, and require a business account to request more subnets. How do I plan a set of internet accessible networks that have to be segregated from each other if I have no idea if tomorrow I'm going to lose those subnets?

The only solution of right now is to use ULA and NAT6. Which is just IPv4's problem all over again except worse.

So yeah it is 'easy' if all your need is just only /64 and are using the ISP's router to setup a single network that you don't care about. But it spirals very quickly into madness when you try to step just a little beyond a simple setup.


I can’t comment on UI Edge routers, but my UDM SE has perfect IPv6 support. Which, granted, is a recent thing (full support for SLAAC arrived about 6 months ago), but no complaints from me about the UniFi line.

Carriers dynamically handing out v6 allocations that change is a major major problem for v6 adoption.

They need to change to static assignments for users and be done with it.


Nice, they will be released, so the blocks can be bought by AWS, etc extractring rents for a long time ... Why don't we switch to ipv6.

They won’t be released, because releasing them would literally wreak havoc on the IPv4 internet.

Releasing them could be the best thing for IPv6 to ever happen.


> Why don't we switch to ipv6.

Because the IPv4 NAT technology exists.


Because of IoT - devices are inherently insecure and they are currently obscured by NAT.

Imagine if billions of printers, weather stations, baby monitors, toothbrushes and thermostats suddenly obtain publicly routeable address...


Consumer routers typically have a firewall. Additionally all those IoT devices are able to obtain these publicly routable ipv6 addresses already in millions of homes, its just the numbers are lower

The main issue is that you can port scan all those IPv4 addresses in minutes. It's impossible for v6 so the issue, even without a firewall, isn't a big issue.

I know you can do address harvesting like it was done with pool.ntp.org by shodan but if you don't use any public services your IoT devices are basically protected by the 128bit address space. So you need a address harvesting possibility, and people are watching for this as seen in the shodan case, and an exploitable issue at the same time. Not impossible and you should use a firewall but orders of magnitude less scary than a public routable IPv4 address.


That's what link-local addresses are good for.

The most likely thing to happen is nothing.

Next most likely is they are re-classed for private usage.

If they are re-assigned for use on the internet they will be assigned to the RIRs and distributed under their policies. No no way AWS are gonna be able to hoover them up like they can when acquiring space from existing holders.


If they get reclassified the RIRs will likely have strict allocation policies for them and only hand them out to new operators.

I remember the days when theregister could be considered good newsource.

Did the author need to crank out an "article" before the weekend?

This has been talked about for decades. It's not going to happen. The entire range is unusable at the networking core level, even if you magically had an OS that accepted it.

You can't tweak IPv4 any more. Accept the fact that while IPv6 may seem scary to some, it's the way we _must_ move.

Networking is not scary, learn it.


> Accept the fact that while IPv6 may seem scary to some, it's the way we _must_ move.

IPv6 availability is far from universal. I have 8 fiber ISPs to choose from. Zero of them offer IPv6.


The point is it’s not terribly difficult for them to offer it if they chose.

That said I don’t feel there is any meaningful technical barrier to using 240/4.


It took many years before mobile carriers in the US supported IPv6. I don't think any carriers here in Ireland do.

My gigabit fiber provider only supports IPv4. Granted, they're just a VNO, using PPPoE on top of Eircom's network. Eir supports IPv6 if you subscribe to them directly, but their customer service is nonexistent and you'll be waiting over a year just for them to hook you up. For now I stay with the VNO because they have excellent customer service, except for not having an answer for me every time I ask them when they'll support v6.


I attended a university which DHCP'd unique, public-facing IPs to every device on the network. Although this requires tens-of-thousands of unique global IPs, the university only utilizes a small percentage of their allocated IP range. Having worked in the IT dept during school, I know it would have been a nightmare to attempt merging ours with another IP-range.

Back in 2006 I gave a presentation on IPv4 end-of-life, when it was then predicted IPv6 would be entirely necessary by 2020 (i.e. that IPv4 would die out by then). This explainer/demo, almost two decades ago, got me a job offer... and yet two decades later I still don't use IPv6, myself!


My university did this and it was great for me as a student. I bought an old workstation from surplus and put it on my dorm room desk as a server. I got to play around a lot with of tech stuff that would have otherwise been out of reach because $5 VPS didn't really exist yet.

>old workstation from surplus and put it on my dorm room desk as a server.

Our dorm did this, with competitions to see "who could upload the most torrent traffic" [i2hub fiber between universities was just becoming popular]. Eventually the MAC address would be blacklisted, and all you'd need to do is replace the NIC and you'd immediately be "back in business."

>I got to play around a lot with of tech stuff that would have otherwise been out of reach

Memories, and it goes by so quickly (my ranting is from two decades ago). Then life gets serious =P


Replacing the NIC sounds expensive, on a college student budget. You could've just reprogrammed the MAC EEPROM, no?

Some answers from my perspective:

240/4 is already useful in sdns, vpns, and networks like AWS as a hop along the way. Merely moving it on the IETF/IANA ledger from reserved to unicast would recognize reality since 2008. It is hilarious how hard that has been.

Universal connectivity need not be a goal - can you imagine a portion of the internet completely immune from 30+ years of windows borne worms and viruses? :)

240/4 support in modern windows is a patch tuesday away which I would hope happen after it is moved from one side of the ledger to the other, officially. It (and 0/8) saves nanoseconds.

In doing these patches we noticed that NO IoT OS actually did the 240/4 or 0/8 check, and in deleting the checks for it in Linux, etc, 5 and 16 years ago, the internet did not melt down.

I see a lot of resentment from the router community that bemoans the extra work it will take to block these addresses, when if they don´t bother, nothing will change. Deleting code and acls for it, will actually speed things up.

The flack I took for the 0/8 patches from thousands of people and the 3 weeks it took to patch that out of everything were outweighed in terms of saving nanoseconds on every packet the first weekend that kernel deployed. 5+ years ago in the case of 0/8. Enforcing a stupid policy for decades for no reason seems silly. 0/8 should have been reclaimed in 1986.

As for what doesn´t work, who cares? Enough networks do already to make the 240/4 space usable. However AWS and google and perhaps others squatting on it!? and turning it into RFC1918 space, was certainly not my intent - I had thought that these addresses should be added to the global internet, for all mankind. Jon Postel would be spinning in his grave if he saw this abuse of this space.

I had delusions of setting up 255/8 (the most junky space available, much like 2.4ghz was for wifi) as a test, as a place to innovate, as a place to perhaps perfect udp-lite natting, and other protocols, within the open source community.

Lastly, everybody misses the most important draft of all, finally retiring the .0 broadcast idea (with no users since 1986) which will free up oodles of real world IPv4 address space. Most of that work is already done, it would take very little to finish it. Why is it so hard to get people to pay attention to that? https://www.ietf.org/id/draft-schoen-intarea-unicast-lowest-...

IPv6 also has a stupid idea about the zeroth address, only implemented in a few places that needs to be depreciated, which would shrink a lot of routing tables.


A reasonable approach imo would be to let the RIRs assign it, but only to networks that can demonstrate they are running v6.

As regards to the zeroth address on multipoint L2 networks would it really help that much? I’m not sure many people are really gonna see massive improvement squeezing one more host onto subnets. Maybe at the smaller end of things, /30, /29, /28 etc.

Orgs are finding they can stretch v4 quite a lot, with load-balancers, proxies, NATs etc. The bigger headache in my experience is acquiring enough routable ranges to assign 1 for each site. A couple of extra hosts at each seems less critical.


Technically, they could¹ be released – but it wouldn’t help! Even a /4 is a drop in the bucket the way allocations were accelerating up until the addresses ran out. They’d quickly run out again, and we’d be back to where we started. Except now with additional problems for everybody unable to use the new addresses.

If you have to exchange old equipment anyway, it’s better to use the new equipment to simply switch to IPv6.

1. With horrible consequences, admittedly.


Legal | privacy