250 million-plus reserved IPv4 addresses could be released – but the internet isn’t built to use them

Activists are again lobbying for more than 250 million unused IPv4 addresses to be released for use, potentially easing the IPv4 exhaustion problem. However, the proposal has been tried and failed before, and again faces formidable opposition. The unused addresses are known as the “240/4” block and comprise most of the IPv4 …

[Jamie Jones]

Cover them all

What they should do is cover all the quirky cases, like the 0.0.0.0/8 block, the 127.1-255.0.0/16 blocks and any others.

They don't have to allocate them - just remove their reserved status from the RFC's, so that *IF* this 240/4 plan ever works, they should all be just as clean. The changes to the stack should be simple - the issue is having to change things at all, so may as well clear out ALL the quirks at the same time.

[John Robson]

Re: Cover them all

`127.1-255.0.0/16`

WTF?

Oh, You mean all of the 127/8 except 127.0/16?

That's a really weird way of writing a network definition, partly because it's a horrible definition...

Might be substantially easier just do the top half (a /9), or to move to IPv6

[John Robson]

Re: Cover them all

I mean it's a horrible range to define in networking terms - it's:

127.1/16

127.2/15

127.4/14

127.8/13

127.16/12

127.32/11

127.64/10

127.128/9

Note that each line gets twice as many IP addresses as the previous (or each line is half as effective as the next)

[Jamie Jones]

Re: Cover them all

127.1-255.0.0/16`

WTF?

Oh, You mean all of the 127/8 except 127.0/16?

That's a really weird way of writing a network definition, partly because it's a horrible definition...

I dunno. It made sense to me; you understood it; and it was an obvious one-liner rather than your 8 CIDR routes.

I call that a win!

[John Robson]

Re: Cover them all

Whilst you and I can understand it, after a second and third attempt at parsing... network hardware can't.

And I don't care how much ML/AI caffeine you throw at it, it still can't.

The 8 CIDR routes are, I think, the smallest available (machine readable) definition of that routing set - and that's what I meant when I said it was a *horrible* range.

[DS999]

Re: Cover them all

Not possible. The standard definition of the loopback network is 127/8, so the interface IP address set to 127.0.0.1 with a netmask 255.0.0.0. You would have to patch pretty much every device in the world that uses IP to change that. That's an even more daunting task than the 240/4 thing, since some stuff like Linux has already been fixed for that.

[Yes Me]

Re: Cover them all

"patch pretty much every device in the world"

All except the IPv6-only devices, in fact.

[Mage]

Re:IPv6-only devices

How much use are they for the Internet generally? Only any good for a totally stand-alone system (LAN or specialist system using the Internet). Many ISPs still don't even do IP6 at all.

[Roland6]

Re: Re:IPv6-only devices

Are there any IPv6 only devices?

Most (dual stack) network equipment seems to out of the box only support configuration over IPv4.

Aside: Because of this I’ve never bothered to find out if my (IPv4/IPv6) router actually supports management interface access from IPv6….

Interestingly, whilst my router permits me to enable/disable IPv6, there is no option to disable IPv4.

[DS999]

Re: Re:IPv6-only devices

Yes if there is such a thing as an IPv6 only device I've seen seen it or even heard rumors of its existence.

[Excused Boots]

Re: Re:IPv6-only devices

Now this is an example of something which always intrigues me about the El-Reg forum members, who and why downvoted the above post?

It's a perfectly valid point, and the truth (albeit an uncomfortable one for some) seems sound. Despite the obvious advantages of IPv6*, the reality is that only a tiny, tiny minority of sites or hosts will be IPv6 only - for 'reasons', mainly because, generally you would like others to connect to it, and without an IPv4, that's really not going to happen.

The comment about many ISPs being IPv4 only is, alas, also true - here in the UK, the second largest ISP (Virgin Media) has been 'working on IPv6' for the past ten years; literally; their official support forum has a thread dating back that long (recently been locked by the mods, presumably it's now become embarrassing), about this with posts from VM staff saying how this is being worked on and is coming soon! Right now they have zero support for IPv6 - I understand that for various reasons, they happen to have a pool of available v4 addresses, so presumably they don't see this as an issue.

Anyhow, back to my original point, why downvote the post? Is it because you disagree with the premise? In which case, fine, rebut it, make a post pointing out the errors, argue your point! Or is it more the case that you wish that the situation wasn't what it is and the downvote is an expression of that?

Maybe we need a more granular system of voting on posts;

Yes I agree with what you say entirely

No, you are entirely wrong and don't know what what you are talking about - and I'll counter it in a post soon (honest!)

You make a good point, wish it wasn't such but......

* And yes, I'm not some kind of luddite, holding out against the inevitable future - I know exactly how IPv6 works, and the advantages it offers. But even so, does it have widespread adoption, I mean, seriously, be honest, does it - why?

[DS999]

Re: Re:IPv6-only devices

I think you are looking for more meaning in people's votes than you should, and trying to further granulate that voting will not give you the satisfaction you seek.

At one time, under a previous nickname, I would inevitably receive at least one downvote for every post I made, regardless of whether that was the only vote it received or it had otherwise received 100 upvotes because no one could possibly disagree with it. I never found out for sure who it was (though I had my suspicions) but someone had taken a dislike to me over something I posted (presumably I insulted some deeply held belief of his, or he made such a stupid post I insulted him directly) and he made it his job to downvote everything I post - which is easy to do, if you click on someone's name here you can see all the posts they made and have an opportunity to vote on them without even reading the article it is about or the context it may be in reply to!

So one or two downvotes in isolation in something I would never question, especially not about a "hot button" issue which in most forums would be Trump or Israel or something like that. But on El Reg IPv6 certainly qualifies as a hot button issue where some people strongly feel it is insanity that we aren't doing everything possible to pressure everyone off IPv4 at the fastest possible pace, and others think that while IPv4 has some clear inadequacies today that IPv6 creates more problems than it solves and was poorly designed to be its replacement.

I tend to fall a bit more in the latter camp than the former, if someone wants to know how to upvote/downvote me solely based on IPv6 views.

[JKnott]

Re: Re:IPv6-only devices

"It's a perfectly valid point, and the truth (albeit an uncomfortable one for some) seems sound. Despite the obvious advantages of IPv6*, the reality is that only a tiny, tiny minority of sites or hosts will be IPv6 only - for 'reasons', mainly because, generally you would like others to connect to it, and without an IPv4, that's really not going to happen."

There's lot of IPv6 only in Asia. You know, little countries such as China and India that have so few IPv4 addresses to serve huge populations. Way back in the dark ages, when the Internet was just starting up, it was largely limited to the U.S. and that's where most of the addresses were allocated, leaving very few for Asia, Africa, etc..

[DS999]

Re: Re:IPv6-only devices

Do they really have IPv6 ONLY devices? Can you point to any, i.e. link to specs that show they do not support IPv4 at all?

[Roland6]

Re: Re:IPv6-only devices

> Do they really have IPv6 ONLY devices?

Suspect not, although with the widespread adoption of 4G I can see there being IPv6 only networks, so a host’s IPv4 interface isn’t publicly accessible.

[DS999]

Re: Re:IPv6-only devices

Agreed, that could work in China due to the Great Firewall limiting their access to the outside world. But nowhere else.

[Roland6]

Re: Re:IPv6-only devices

Don’t know could work here…

Although, having a website with only an IPv6 address, might be handy for the dark web or even as a security through obscurity protection…

[JKnott]

Re: Re:IPv6-only devices

"> Do they really have IPv6 ONLY devices?

Suspect not, although with the widespread adoption of 4G I can see there being IPv6 only networks, so a host’s IPv4 interface isn’t publicly accessible."

That's the case with my cell phone. It's IPv6 only and uses 464XLAT when needed to access IPv4 only sites.

[JKnott]

Re: Re:IPv6-only devices

"Do they really have IPv6 ONLY devices? Can you point to any, i.e. link to specs that show they do not support IPv4 at all?"

Android phones use 464XLAT to access IPv4 only sites over the IPv6 only cell network. My current and previous cell phones worked that way with IPv4. They get a public IPv6 address and /64 prefix. For IPv4, the address is 192.0.0.4, which is used with 464XLAT.

[Jamie Jones]

Re: Cover them all

That's not the point I was trying to make.

I know loopback is 127/8 , and I know it would be more involved to achieve than the 240/4 change.

My point is that 20 odd years ago, 240/4 was deemed too hard to do. If the spec had changed, without even specifically force-upgrading kit, most stuff would be compatible now.

127.0/16 has been proposed many times. I'm just simply saying if you're going to change the spec, cover all possible use cases. Nothing has to actively promote change to with 127.0 or any of the others, but if in 20 years time, there is a sudden need for it, we'll be in a better position, just like if 20 years ago, the said "define 240/4" as part of the normal address space, and just did nothing else, natural churn would put us in a much better position today.

[dtaht]

Re: Cover them all

We did:

Probably the most important proposal was finally retiring fully the concept of 0 as broadcast: https://www.ietf.org/id/draft-schoen-intarea-unicast-lowest-address-05.html

That work is mostly done too, codewise.

So is 0/8. I´m really fond of that patch - deleted 5 lines of code and saved every computer on the planet a nanosecond or more on every packet.

Two MUCH more controversial proposals were limiting ipv4 multicast address space (which I do not feel like pursueing at this time), and shaving down 127 to something sane, and making it work with k8.

[Jamie Jones]

Re: Cover them all

Oh thanks. I'm glad everything was looked at.

As I said in another post just now, I know some of these would be quite difficult to achieve (like 127.0/16) but my point was just that changing the spec without actually promoting the need for updates would put us in a better position if these things reared their ugly heads again in 20 years time!

[JKnott]

Re: Cover them all

Why not move to IPv6 and get rid of broadcasts entirely? Since broadcasts can cause a performance hit, IPv6 has moved everything to multicasts and the equivalent to a broadcast is the all nodes multicast.

[Jellied Eel]

Re: Cover them all

Why not move to IPv6 and get rid of broadcasts entirely?

Because at times, broadcasts can be a very simple and useful way to communicate on a LAN.

Since broadcasts can cause a performance hit, IPv6 has moved everything to multicasts and the equivalent to a broadcast is the all nodes multicast.

Depends what you mean by performance hit. Multicasting is more complex and thus more expensive to implement, potentially causing a performance hit. If by performance hit, you mean the risk of broadcast storms, thats often a problem with design/configuration of your network. Mostly at the Ethernet level, and with the rise of EVPNs, we created the ability for broadcast storms to go global. Multicast storms are a thing however, and can be very easy to trigger if networks aren't designed carefully.

Part of that challenge is in order to simplify large Ethernet networks, MMRP (Multiple MAC Registration Protocol ) and MVRP (Multiple VLAN Registration Protocol) crept into 802.1Q via 802.1ak, allowing the ability to-

https://en.wikipedia.org/wiki/Multiple_Registration_Protocol

This information allows MVRP-aware devices to establish and update dynamically their knowledge of the set of VLANs that currently have active members, and through which ports those members can be reached. The main purpose of MVRP is to allow switches to automatically discover some of the VLAN information that would otherwise need to be manually configured

Whether that's a good thing or a bad thing probably depends on your view wrt security and how much you trust your vendor's automagic and what suprises you might autodiscover. As VLANs are really a way to isolate traffic, I much prefer manual configuration and not discovering traffic from a node on a LAN or VLAN that it shouldn't be on. Add IPv6 mcast and all-nodes into the mix and it can be a great way to autodiscover a target network though.

[JKnott]

Re: Cover them all

"Depends what you mean by performance hit."

Broadcasts were around long before multicasts. As a result, they were often used when a multicast, to a smaller group, would have been more appropriate. With a broadcast, the device receiving it has to stop what it's doing, process the broadcast to see if it's interested and then resume. With multicasts, the device only listens to what it wants and unwanted multicasts are discarded by the NIC.

[Roland6]

Re: Cover them all

> Why not move to IPv6 and get rid of broadcasts entirely?

Sometimes you need the megaphone; try talking to a crowd via Chinese whispers or a cascade of focus groups…

Remember IPv6 allows for some very large subnets, being able to “shout” at all members is useful.

[JKnott]

Re: Cover them all

"Sometimes you need the megaphone"

The IPv6 equivalent is the all hosts multicast. That will be received by all devices on the network. It's typically used for router advertisements etc.. By using multicasts, instead of broadcasts, you can focus on the intended audience only and not bother everyone else.

[Dimmer]

Re: Cover them all

From an earlier life before IPS, I built a crude IPS by adding 192.168.xxx 10.xxx and so on to an acl with logging. I also knew my expected public exposure and logged any thing that was not expected on that ip and port as well.

The router syslogged out to a server. With a bit of programming, the program on the server would add a route to the router for anything I did not like. If it was persistent, the application would send me an email.

I received an email that I was being attacked by 127.0.0.1! (Spoofed naturally) and the router was forwarding the packet. The Checkpoint firewall did not logg it or block it. It just did not exist to any software firewalls.

Using what is now called Wireshark, tapped and grabbed packets. 50% of my bandwidth was these packets and nothing was seeing it except my router.

With the ISP’s help, and we had to put acls on their routers to see it, we tracked it upstream and found the bot server. They were crafting the packets for control of the bots and blew this to everyone. They never expected a return packet nor did the Chinese student that had his dorm door busted in and server taken.

That said, I block all addresses that are not listed as public from entering or leaving our networks.

[DJV]

Re: Cover them all

Hmmm, I wonder if your downvoter used to be a Chinese student...

[Mage]

Re: Cover them all

Also the giant blocks handed at the start to some USA companies, USA Universities and USA Government. Dwarfs what Radio Amateurs got, and who exactly had the authority to sell those?

Related: You can't buy a domain name. Only rent it. That needs fixed too,

[jmch]

Future use??

- If 240/4 was reserved decades ago for 'future use', I would think that it's about time they were tapped into as a resource

- Why would individual routers' firmware be set up to ignore 240/4 addresses? If anyone mistakenly sends requests to any such address they would simply time out just like a normal wrong address. What harm could a few stray requests do compared to having to firmware-update or change each and every router in the world?? Very curious design choice, that!

[biddibiddibiddibiddi]

Re: Future use??

You'd be surprised by how much of the RFC1918 address space does get advertised for routing over ISP networks, which is a potential vulnerability if someone tries to connect to it and ends up reaching a malicious server. Most devices SHOULDN'T be handling packets for those blocks outside their WAN generally, and never advertising routes via routing protocols, but there's technically nothing that says you can't use a router internally at multiple points where such routing would be valid so outright preventing it wouldn't be good and it comes down to either bad configurations or malicious configurations. But 240/4 being reserved as a "never use this" block makes it a bigger deal to prevent anything on the public Internet ever accepting routes or sending traffic for it. Kind of an arbitrary dividing line between degrees of risk, I guess. But after we reached the point of not having anymore IPv4 addresses, and deciding that IPv6 was the future, 240/4 should have been released as there was clearly never going to be any other "future use" or experiments. (And what did they need 168 million addresses for when experimenting?)

[Roland6]

Re: Future use??

“Reserved for future use”

So what do stupid manufacturers interpret this to mean? Block its possible future use…

“ The reasoning is that many manufacturers of networking equipment don’t recognize 240/4 and simply won’t process packets sent to the millions of addresses the block contains”

Interop failure.

Aside can’t find a RFC which defines what action should be taken with future use addresses and RFC3330 doesn’t give any either. So default behaviour should be for routers to treat these addresses as normal IPv4 reputable addresses.

[Yes Me]

Re: Future use??

"can’t find a RFC which defines what action should be taken"

Nobody has invested significant R&D or RFC-writing effort in IPv4 itself since July 1994 when the IPv6 decision was taken. This current effort to mess about with unsupported address space has approximately zero support in the IETF.

[Roland6]

Re: Future use??

The (poor) quality of the RFC’s compared to the OSI specifications, was one of the issues identified back in the 1980s. The 240/4 issues is just another example of the fundamental problem, where lack of rigor has resulted in differing interpretations and thus differing implementations.

[EvaQ]

Re: Future use??

"The (poor) quality of the RFC’s compared to the OSI specifications, was one of the issues identified back in the 1980s."

Does X.400 count as an OSI spec? If so:

As an intern, around 1990/1991, I implemented an X.400 system (of course over X.25) at a government. What a horror, because of all those specs.

I used SMTP at the university, but expected X.400 would be much better, because of all those great features and specs. Not so. That was quite a lesson for me: KISS.

[Roland6]

Re: Future use??

> Does X.400 count as an OSI spec?

Good question…

To some as it was incorporated into ISO OSI the answer is yes. However, it was developed independently to OSI and as you note it was intended to operate directly over X.25, so contained some duplication of transport etc.

As to whether X.400 was or was not better than SMTP and Sendmail, well they came from two different viewpoints…

My point was if you had tried to implement a mail system on SMTP, you would have been using the relevant RFCs as your specification and probably would have decided to port someone else’s working code…

>KISS

The MAP/TOP initiative did a good just of cutting through the ISO OSI specifications, creating an OSI profile that was broadly equivalent to TCP/IP, which cause outrage among some in the OSI movement… The trouble with MAP/TOP was they really showed the need for application standards ie. File formats and messaging/api’s; here we are nearly 40 years later and still this is the problem….

[Terje]

Re: Future use??

This shows more about how the IETF needs to sort themselves out then the underlying issue. While I wholeheartedly agree that ipv4 is a problem, I don't believe that ipv6 is really the answer, since it's one misconfiguration of my router away from exposing everything inside to the world. If ipv4 were to disappear today which seem to be pretty much what IETF wants then there would be even more carnage with intrusions then there already is since firewall configuration is significantly harder to do properly when you don't have a nat under it providing another layer of isolation when you are either a home user with no clue, or as in my case someone with enough knowledge to be dangerous.

[Anonymous Coward]

Re: Future use??

240/4 is on the list of Bogon addresses. Basically if you are a router on the public Internet and you see packets to/from addresses on the bogon list, something has gone very wrong, and the reccomended thing to do is to drop the packet. (Or at least that was reccomended practice back when I was configuring Cisco 2501 routers).

Like you said, that probably shouldn't be hard coded in the firmware. Years back we used to manually update our bogons lists when new blocks were assigned to regional registries (ok, ok, actually 6 months later when someone complained about issues).

The only special thing about 240/4 was that by saying "future use" instead of "unassigned" there was greater uncertainty about what you would eventually see from those addresses. Maybe someone thought that the risk of oddball packets was too great to trust to the config layer.

[Anonymous Coward]

Re: Future use??

1.1.1.1 was in the bogons wasn't it?

[Mike007]

Re: Future use??

Some people generated lists of every IP address "not currently assigned" and put it in to a static config as blocked, like the above poster. This was always something they had been explicitly told not to do. (If you want to drop packets from currently unrouted space, you should use BGP as your source for the lists updated in realtime)

When 1/8 was allocated to APNIC they had to go through the process (which they did for every single /8 assigned, due to the above) of convincing people improperly blocking newly allocated space to update or remove their lists. They did this by advertising it on the global internet and doing measurements to see how widespread the blocking was before actually allocating the addresses to network operators.

1.1.1.1 is permanently screwed (along with 1.0.0.0/24 and 1.2.3.4) for a different reason though - "oh this hasn't been allocated yet, and is a nice easy address, so let's pretend it is RFC1918 space".

During the above mentioned testing, as soon as they advertised the 1/8 prefix it knocked the entire measurement network offline because of the massive volume of junk traffic originating from networks improperly using this space. They had to request help from "the giants" to see how much traffic was actually being directed towards that prefix.

Cloudflare are allowed to use it due to the fact that they said they were willing to absorb Gbits of bogus traffic in exchange for a "cool IP". You will note that it is not actually assigned to cloudflare, it is assigned to APNIC R&D with an official policy that it will never be a public allocation.

[DS999]

Re: Future use??

Cloudflare are allowed to use it due to the fact that they said they were willing to absorb Gbits of bogus traffic

I imagine there is (or at least one time was) some potentially useful or valuable information buried in those Gbits of bogus traffic if you knew where to look - people testing various stuff and sending to 1.1.1.1 as a "test address that's 'on the internet' but doesn't have anything there to respond".

[Mike007]

Re: Future use??

It would actually be interesting if anyone has a reference to a more recent report on the situation with this IP space. The fact that it is technically R&D space means they will likely be sharing information with APNIC about the traffic they are observing.

If they had merely reserved it as per the original plan then I suspect it would still be unusable, but cloudflare putting a massively popular service on there will have forced a lot of networks to fix things they otherwise would have ignored. I believe this is considered a "win win situation" with regards to the goal of rehabilitating previously unusable IP space :)

(for the record, when I first heard about this cloudflare thing I was not supportive of it and thought it unethical to give "special treatment" to a big company - I have since changed my position on this)

[Daniel B.]

Re: Future use??

I think the entire 1/8 address space was, or at least 1.1/16 and 1.2/16 due to how much traffic they’d get on those networks due to misconfigured stuff with 1.1.1.1 or 1.2.3.4

[Benegesserict Cumbersomberbatch]

Re: Future use??

So at some point a decision has been made to translate "reserved for future use" to "that future will never arrive, so treat anyone trying to use as malicious or erroneous".

Striving for the future, but don't realise that we're in it."

-The Cat Empire, Nothing

[jmch]

Re: Future use??

"Bogon addresses"

Curious here, is 'bogon' some archaic technical term, or something more colloquial, akin to fubar???

[Autonomous Comrade]

Re: Future use??

The term bogon stems from hacker jargon, with the earliest appearance in the Jargon File in version 1.5.0 (dated 1983). It is defined as the quantum of bogosity, or the property of being bogus. A bogon packet is frequently bogus both in the conventional sense of being forged for illegitimate purposes, and in the hackish sense of being incorrect, absurd, and useless.

- https://en.wikipedia.org/wiki/Bogon_filtering#Etymology

[Roland6]

Re: Future use??

Both!

APnic definition:

What is a Bogon Address?

[Ken Moorhouse]

Re: Bogon addresses

No sorry, you can't have two for the price of one.

[the spectacularly refined chap]

Re: Future use??

Why would individual routers' firmware be set up to ignore 240/4 addresses? If anyone mistakenly sends requests to any such address they would simply time out just like a normal wrong address.

That may or may not be the end result depending on the set up of the routers involved in the the process, the other is an ICMP unknown/unreachable message. Regardless of the result the end user sees an awful lot of work is being wasted.

Without a filter in place your router will simply send the entire packet to it's default route (generally your ISP). If the receiving router is also configured in the same way then it then forwards the entire packet to it's default route until it reaches a level deep in the network core that has a true global routing table: i.e. there is no "default" route, it has a specific route for any address. Those routers are big, expensive and highly loaded, they typically have 100,000+ separate routes to manage even after summarisation.

It would only be at that level the decision can then be taken "sorry, can't send to that address" after wasting a lot of time and bandwidth in the process.

[Roland6]

Re: Future use??

This is what happens today if you try sending a packet to a host in an unassigned address block.

Given this is an unassigned address block, I suspect the number of instances of systems trying to send stuff to it is miniscule.

[doublelayer]

Re: Future use??

The risk that someone treats "unused for now" as "I can do whatever I want with it", it gets switched to "used for something different" and all the traffic breaks something. When the block was first reserved, "future use" might have meant that you send traffic to those addresses that might not be compatible with the existing specification; it was not stated which of the details would stay the same when they were eventually put to use. For example, we had a discussion a couple weeks back of companies who used a domain name they do not control for internal company stuff. If you never make a mistake, that's not going to cause any problems. If you have any misconfiguration, you will start to, at the very least, leak your internal names to an external DNS server, and possibly route to someone else's servers which could be quite dangerous.

Ideally, routers would configure such things in software. It would, by default, treat 240/4 as a range that might not act like normal ones and therefore wouldn't pass traffic intended for them, but there would be a table of addresses that were handled like that and people could remove the block. However, if you're going for speed, you might implement that logic in hardware and not bother to make it configurable. The same is true if the people building the hardware assume that the address space won't be used before this hardware is obsolete, and when it is used it will need custom software to handle which won't be written for obsolete hardware, so they shouldn't add it in. So, unfortunately, most equipment was not built to make it simple to disable that behavior.

[xyz123]

Re: Future use??

Ignoring whole blocks is a MUCH faster process than trying to parse data that isn't going anywhere anyway.

Easier to just thow data away aimed at those addresses.

[Dan 55]

Re: Future use??

"It says here reserved for future use."

"Ah, that must mean we have to make those addresses impossible to use in the future. Right ho..."

[doublelayer]

Re: Future use??

Actually, you might want to, in case the future use is eventually defined as something that's incompatible with the protocol you've supported. For example, there are a lot of file formats with a version field. Version 1 is already defined, and my program supports it. I should not treat version 2, currently reserved for future use, as a flag that anyone can use for whatever purpose they like and treat it identically as version 1. I should not do that because, if version 2 does come out, my program will be treating it incorrectly rather than just telling people to install the update that handles it properly. An update to set version 2 as equivalent to version 1, should that prove to be how version 2 works, doesn't break things in any other situation. I think the 240/4 handling should have been a configurable option, but it absolutely should have been blocked by default.

[Dan 55]

Re: Future use??

There was nothing to indicate that that address range would be incompatible with the rest of the address space in some way. There was no instructions to block this address range off because it (and only it) might use an incompatible IPv4.1 in the future. "Actually you might want to" is not a good enough reason.

Many routers already treat it the same as the rest of the reserved address space (i.e. let it through and it'll time out if there's nothing at the other end) because their manufacturers can actually read the RFCs and when it does finally get a future use the chances are it'll use the same protocol as the rest of the address space - what possible practical use would there be in making ≈ 16% of the iPv4 address space incompatible? Letting it through means it's cheaper for manufacturers in terms of future updates and least likely to cause them support requests from customers as their equipment works in the way they expected.

If somehow it did turn out to be incompatible then an update would fix that, otherwise treating that address space as unallocated in the same way as other reserved blocks is the right thing to do otherwise you end up with precisely the idiotic situation we have before us today where lots of people need updates to fix something which should have just worked anyway - but they're not going to get them because their equipment is out of support.

[doublelayer]

Re: Future use??

The RFCs do not say that you must drop it, but neither do they say that you must pass it. It says "reserved". How you implement that is up to you, but there is a difference between using it as normal space in your own network and assuming that sending traffic to the internet should also work. For example, we could also free up lots of space in the 127/8 block because nobody needs that many loopback addresses, but it would not be acceptable for me, as your ISP, to decide that I'll take all those addresses and send traffic you send to them out to whatever boxes I put there. It would not be acceptable because the protocol specifies that I should not, and the protocol also specifies that those addresses are reserved, not for definitely using on the public internet but not right now, but for some unspecified future use which might not be standard.

[Roland6]

Re: Future use??

The RFCs…

A review of the relevant RFC’s and their status and dateline clearly show the IETF are themselves the cause of the problem with 240/4…

RFC1700 (October 1994) - the last RFC to mention Class E aka 240/4, was replaced by an online database of numbers in 1994, it was only obsoleted in 2002.

Given the massive growth of the internet, resulting in it moving out of academia into the commercial world, along with the knowledge that IPv4 addresses would run out - hence IPv6 and the imminent sunsetting of IPv4, it is somewhat surprising the IETF retained an address block for some unspecified research purpose rather than change its status to unallocated in 1994…

[Roland6]

Re: Future use??

The IPv6 address space might in theory be very large, but given the issues around IETF’s use of the word “reserved”, it may be artificially limited:

“ In order to allow efficient route aggregation, thereby reducing the size of the Internet routing tables, only one-eighth of the total address space (2000::/3) is currently allocated for use on the Internet. The rest of the IPv6 address space is reserved for future use or for special purposes.”

[ https://en.wikipedia.org/wiki/IPv6_address ]

Okay it’s Wikipedia, but clearly in the light of the 240/4 issues, some research and clarification is necessary.

[JKnott]

Re: Future use??

"The IPv6 address space might in theory be very large, but given the issues around IETF’s use of the word “reserved”, it may be artificially limited:"

In that 1/8th the address space there are enough addresses to give every single person on earth over 4000 /48 prefixes. Each /48 contains 2⁸⁰ addresses. Yep, really limited!

[Roland6]

Re: Future use??

The “limitation” of v6 is the subnet hierarchy that results in the /48 or /56 allocation which some ISPs handout. Not saying it’s as limited as v4 (or a limit we will be bumping into anytime soon) but it’s not as big as some would like to believe, as it was designed to facilitate core routing and keeping core routing tables small.

[JKnott]

Re: Future use??

"The “limitation” of v6 is the subnet hierarchy that results in the /48 or /56 allocation which some ISPs handout."

There are enough /48s to give every single person on earth over 4000 of then.

[Roland6]

Re: Future use??

> in case the future use is eventually defined as something that's incompatible with the protocol you've supported.

Err no , by definition, we are talking about the IPv4 address space used by all IPv4 implementations, if a future use is incompatible with IPv4 as specified and deployed then you should be using the protocol version field to cause routers to redirect the IP packet to the IPvx processor, just like IPv6…

As noted blocking can be achieved via correct use of BGP.

Interesting, related but slightly different, I’ve not come across an implementation that blocks the use of reserved TCP/UDP ports…

[doublelayer]

Re: Future use??

Reserving something for future use kind of implies that you have a reason. Not just "so far unassigned". For example, phone systems often have certain codes that are reserved for future use. When those get removed from that list and put to real use, that tends to happen when something has changed, and the numbers look different. For example, the length of a phone number in a system that uses variable lengths is usually decided when the prefix is put in production, not before. As it happens, we didn't make any changes that would make use of the numbers in a different way, but they easily could have put those addresses on a list and would have if they hadn't imagined that something could change in a way that required a contiguous address block that wasn't in use.

[networker]

Re: Future use??

The reasons routers would drop packets with a 240/4 destination address is for compliance with RFC 1812, s5.3.7 which says:

> An IP destination address is invalid if it is among those defined as

> illegal destinations in 4.2.3.1, or is a Class E address (except

> 255.255.255.255).

> A router SHOULD NOT forward any packet that has an invalid IP

> destination address or a destination address on network 0.

And this was the justification for needing to implement this in IOS CEF when I worked at Cisco in the CEF team (and a customer request for compliance with this part of the RFC).

Destination address checks in any non-trivial packet forwarding implementation are essentially free, even in software, due to use of optimised forwarding lookups like mtries/Patricia tries. Source address checks cost cycles, but even then it was deemed acceptable to spend them on other s5.3.7 provisions for source addresses.

[Roland6]

Re: Future use??

Which rather nicely contradicts the “reserved for future use” caveat found in other prior and later RFCs…

Given 240/8 was only defined and reserved in 1989-08 (RFC1112), you would have thought there would be some indication (ie. a proposal) of what IETF had in mind as a possible use of this address range.

My guess is having allocated Class D (1110 0000), the IETF were left with the anomily of the last block (1111 0000), and decided to fudge matters by hand waving at possible future requirement, thinking IPv6 would replace IPv4 in a couple of years…

As for RFC1812 s5.3.7, it wrongly declares Class E addresses as “invalid”. Instead, it should have reinforce the use of ACL and BGP.

[biddibiddibiddibiddi]

And if they had just done it in 2008, before it had become so critical, virtually every device in current use would be able to handle it by now. If they had come up with some "new or experimental use" according to the original purposes of the block being reserved, the same thing would have had to happen anyway.

[Anonymous Coward]

IPv6

IPv6 can provide the address space

[alain williams]

Re: IPv6

No more excuses, it is not that hard.

My hosted servers have used IPv6 for 20+ years, I have had IPv6 at home for 15 years.

[AndrueC]

Re: IPv6

I made my mail server(*) accessible over IPv6 several years ago. It wasn't all that difficult. Using a competent ISP that has supported dual-stack IPv4/6 for over 15 years helped of course.

(*)Sits in my spare bedroom.

[Graham Dawson]

Re: IPv6

So, not Plusnet.

[Steve Davies 3]

Re: Plusnet

Have no real excuse for not enabling IPv6. All their crappy routers will ignore it. Only those of us who have replaced their shit with our own routers will see it.

I've stuck with them because of two things.

1) I paid £5.00 for a fixed IP at least 10 years ago. The idiots who run the FTTP/FTTH network around here (TOOB) want £5.00 per month for the same thing. I'd really like to know their justification for that.

and

2) when I have had the odd problem I get to speak to a human who does not try to make out that it is my home network that is at fault (Hey Talk-Talk and Vermin... are you listening)

Come on PlusNet give us IPv6 it isn't that hard you know.

[MatthewSt]

Re: Plusnet

Toob don't want £5 / month for fixed IP address, they want £5 / month to give you an IPv4 address that isn't behind CGNAT. This is how the new boutique fibre providers are keeping the headline costs lower.

[Yes Me]

Re: Plusnet

And it's the OPEX of CGNAT that is driving more and more ISPs to switch to IPv4-as-a-service instead. After a while, it'll become IPv4-as-a-service-for-extra-money.

[JKnott]

Re: Plusnet

I get 2⁷² public addresses from my ISP and my prefix is virtually static. None of this sharing one, count 'em, one address among multiple devices with NAT.

[Anonymous Coward]

Re: IPv6

Exactly. If you need to upgrade routing equipment for extra IPv4, you might as well go the whole hog and upgrade it for IPv6.

[Roland6]

Re: IPv6

Bet there is some daft mess in the IPv6 address space and given the problems with 240/4 are wholly down to manufactures making stupid decisions, would not also be surprised if many IPv6 implementations contain daft constraints that will bite in the future.

[jamesb2147]

Re: IPv6

Certainly true!

But the same was true of v4 and we adopted it anyway, and things have been mostly fine. We invented NAT and it solved some of the biggest problems.

FWIW, the lived experience on v6 is measurably better; search for "happy eyeballs" sometime and you'll find v4 vs v6 stats, with lower latency and higher service utilization by v6 users. It turns out, v6 bypasses the middleware doing inspection and such that was never designed for v6, and it's a better internet for everyone for the moment!

[R Soul]

Re: IPv6

"We invented NAT and it solved some of the biggest problems"

you forgot to add "replacing them with a shitload of even bigger problems".

[I could be a dog really]

Re: IPv6

I guess the downvotes came from people with no idea just how much breakage NAT creates, and the amount of effort that's had to go into working around that breakage.

Of course, if your entire experience of "the internet" is "fire up a browser and watch cat videos" then not much is broken by NAT.

[JKnott]

Re: IPv6

"We invented NAT and it solved some of the biggest problems."

And in the process broke some things that require more hacks to fix.

Trying to stick with IPv4 is anally retentive.

[JKnott]

Re: IPv6

I've been running IPv6 for almost 14 years and haven't noticed any "daft mess" yet. It just works.

[steelpillow]

Re: IPv6

A big problem with v6 is that many links rely on NAT. For example my mobile router NATs anything I connect through onto the carrier's PLMN. It emerges from their gateway with whatever random IP they care to apply. As IP continues to ripple outwards/downwards through the mobile core, converting to v6 means replacing vast numbers of consumer units. Not going to happen.

[Yes Me]

Re: IPv6

Of course it will happen. All consumer units get replaced in the long run.

[JKnott]

Re: IPv6

My cell phone is on Rogers in Canada. It uses IPv6 exclusively and if it needs to connect to an IPv4 only site uses 464XLAT to convert. In addition, tethered devices get a /64 prefix, which means up to 18.4 billion, billion addresses are available to tethered devices.

[Eecahmap]

Where's my share of the sale?

To the author: I've been a licensed ham for 34 years. I didn't receive anything for the partial sale of 44/8.

[Joey Potato]

Re: Where's my share of the sale?

Well, you can get funding from the Amateur Radio Digital Communications Foundation for your project if you apply for a grant. ARDC uses proceeds of the IP address sale fund their whole operation.

[dtaht]

Re: Where's my share of the sale?

ARDC has funded some really great projects, and is always looking for more. I think they have used their share of the proceeds from their sale wisely and well.

https://www.ardc.net/apply/grants/

I wish they would sell off (or rent) even more of the still mostly unused 44 block and help more hams get onto ipv6, and keep working on getting more ham stuff back into the public consciousness, and also able to relax at least some of the amateur processes to make ham radio a viable BGP internet fallback in case of emergency. Investments into wifi would be nice too, but I think slightly out of scope.

[Jason Bloomberg]

10.*.*.*

"240/4 could be added to those pools to help “large private Internets that require more address space than is available in the private use address space designated by [RFC1918] during the dual stack transition to IPv6."

Perhaps I am missing some nuance but large private internets can use 10.*.*.* - That provides nearly 17 million unique addresses.

"Analysis of global internet traffic suggests Amazon and Verizon Business use it internally, too."

Does it still count as internal use when it is global internet traffic?

[Mike 'H']

Re: 10.*.*.*

Essentially this would have helped Comcast right about the time they happened to sign up more than 16.7 million settop boxes / cable modems. There were overlapping RFC1918 networks at different cablecos when Comcast bought them and then needed to combine and integrate everything.

This right here, individual addressibility to EVERY cable settop and EVERY modem on their network was THE push for everything on their network to go ipv6 so they actually could have enough address space for their internal equipment. This has apparently given them a decade+ leap on the rest of the ISP industry.

I just wish other network providers *Centurylink/QuantumFiber I'm looking at YOU* would even turn up NATIVE DUAL STACK..

Hell, their most recent GPON fiber router doesn't even properly run the 6rd tunnel layer they've provided for a decade+ now.

[Soruk]

Re: 10.*.*.*

That's what 100.64/10 was for - CGNAT deployments, and being a separate block it's deliberately not going to clash with customer use of RFC1918 space. See RFC6598.

[ssharwood]

Re: 10.*.*.*

Yes because internal use of the 240/4 block shows up in global traffic. It's still internal use ... but evidence leaks

[Jellied Eel]

Re: 10.*.*.*

Yes because internal use of the 240/4 block shows up in global traffic. It's still internal use ... but evidence leaks

Normal for Internet. How much leaks is maybe a way to test releasing it and how many systems are currently able to support it. As 240/4 was 'reserved', there was obvious scope for future use. I doubt many implementations are done in fixed hardware, so prepping for it's release is mostly a software update issue. For a while, MS didn't permit 240/4 to be configured on an interface or DHCP, now I think it does.

I think there's also the question of resource requirements, and maybe some scope for improving bogon/martian filtering. That can be extended to also include hijacked netblocks and there are services like this-

https://www.team-cymru.com/bogon-networks

to help automate filter building. It's also where this happens given it's mostly an edge function, ie preventing bogons entering the network from edge or peering routers. 'Core' routers don't often need much of a routing table, only the routes specific to that AS and a default if it's not. So it's not necessarily that drastic of a change to allocate 240/4. Then again, if some providers are already using it internally, there would be the potential of overlaps, but that's too bad as strictly speaking, it shouldn't have been used. There is also scope for more address space from 0, 127 and 255, ie 127.0.0.1 is a /32 and doesn't need to be a /8 but allocating from those blocks would likely be a.. bit more challenging.

There have also been suggestions to mandate services like Cymru's, but auto-filter building comes with obvious risks, so it could be attacked, or regulated. There's a regulatory risk that there could be demands to drop routes like Russia, Iran, the US etc for political reasons, but this can already be a condition in telco licences anyway.

[John Brown (no body)]

I propose a new solution

My solution is brilliant. It may cause a few hiccups in the short term, but long term it will solve all of our IPv4 issues for the foreseeable future.

ALL IPv4 addresses will be rescinded and taken back into central control. One and ONLY one IPv4 address will be provided irrevocably to each and every nation on planet Earth. Each nation can do what it wants internally, but ALL outside connections must be NATed via their official IPv4 address.

This will allow for expansion of the Internet in the future to cover other planets and solar systems for many, many years. I'm not sure yet what to call it when it goes interplanetary, or even interstellar, but for now we can call it National NAT or NatNAT for short

Problem solved. If you want to send me my Nobel prize, please contact ElReg with the above username which they can link to my email address to forward your communication.

NB. Anyone who paid for their IPv4 addresses can get stuffed. They were supposed to be free or at nominal admin cost, not a traded commodity. If this affects you, well, sucks to be you, eh?

[katrinab]

Re: I propose a new solution

There are, depending on how you count them, about 170 different nations on earth. You definitely don't need the entire IPv4 address space for that.

[Screwed]

Re: I propose a new solution

Imagine that Regland Kingdom has a revolution and becomes the Republic of Regland, they will want nothing to do with the old assigned IPv4 address and will demand a new one. (Even if they keep using the old address.)

Then, when the Republic of Regland splits into South Regland and Reglandia, the same will happen again. With the added issue of neither of the new nations accepting the other controlling the old IPv4 address(es).

In time South Regland and Reglandia settle their differences and become United Regland. And again, to mark the occasion and avoid ending up using two addresses, or one address taking precedence over the other, they need another new address.

[katrinab]

Re: I propose a new solution

I still think we'd manage with a single /24 though.

[steelpillow]

Re: I propose a marginally less drastic solution

Kinder to just allocate the 255.x.x.x block to this kind of scheme. And rather than NAT as we know and love/hate it, a second-generation extension protocol might be considered. For example any address in the 255.x.x.x range triggers a "there is another one to follow" flag, thus creating a 56-bit (255.x.x.x + x.x.x.x) address range.

Could then recall the odd extra v4 block as another range of flagged extensions, if/when we ever run low again.

Actually came here to propose this but YBMTI.

[Anonymous Coward]

Re: I propose a marginally less drastic solution

but then, the 255.x.x.x range would not be compatible with current IPv4 equipment until it was upgraded with your new spec. And if that upgrade is gonna happen, may as well add ipv6 too... at which point, your 255.x.x.x address mangling in unnecessary

[steelpillow]

Re: I propose a marginally less drastic solution

Any change is likely to require some kind of kit uplift. For most routers, enabling the 255 block should need no more than a software/config update. I'll bet more than you think will just pass it through already. I mean, why would C. Heap Shitt implement rules for stuff that "doesn't exist"?

The plain 255 block address could be allocated to a re-router (call it a v4++ gateway). Any v4 kit would forward the 255 traffic to the gateway, which would pick up on the v4++ flag and re-route. Not totally unlike the NAT principle, but no need to cache the source IP on the gateway because it persists in the wrapper. There are probably smarter compatibility solutions than that out there.

Of course, some users like the IP-masking anonymity that NAT offers, saves a two-ended VPN or superslow TOR, so that's another reason why kissing v4 goodbye is a pipe dream. Indeed, the anonymity of NAT is surely the main flashpoint to any alternative offering: does we does or does we don't?

In fact, I'd go so far as to say that if v6 evangelists want to make real headway, get a v6 NAT-style anonymiser out there. The spooks will hate you for it, but you can't have everything.

[doublelayer]

Re: I propose a marginally less drastic solution

And every piece of software attached to a 255.* address would have to handle that protocol. If you connect to software running on my computer which creates its own streams, it can use a variety of libraries to create the packets it is sending. Not all of them support your arbitrary protocol, and at least some of them are going to need to. You can't abstract that out into one implementation of TCP, for example, because the existing functions for making TCP connections don't have a variable-length address parameter so anything calling them has no way to create a connection to a longer address. The 240/4 address space is theoretically easier because it looks like any other IPV4 address, so most libraries have not bothered to treat it differently, but even that has a lot of systems that need software changes to handle it.

Whenever you replace a network standard, you have to change almost everything that interacts with it. It's not just the routers in the middle that may be older, but software at the edges as well. No matter where you add extra data into the IPV4 address, that is changing the protocol. Software can't handle it. You are more than welcome to build your own proxies which route traffic sent to one IP address to multiple subaddresses on your network, then write software to understand that protocol, but if you think that it can be done to the entire world more conveniently than adopting an existing and mostly supported alternative like IPV6, you're probably misunderstanding something.

[Anonymous Coward]

Re: I propose a marginally less drastic solution

Standard routers may already route to the 255.* address without modification, sure, but what about the second "piggy backed" packet? Now even, if your "new protocol" instead encapsulates the traffic within the remaining packets, that may make it compatible with core routers, but they aren't the problem - the problem is the stack on the users end, which would not work unless updated, and as I said, may as well go ipv6 at this point and avoid the kludge.

Or in summary, your proposal may help reduce the need for core network router upgrades, but guess where ipv6 has been running for years? ipv6 is global - apart from the cogent/HE issue, which is purely political, it already spans the world. It's the user end points that are the sticking point, and your kludge does nothing to address that.

And I resent the term "evangelist" - Ipv6 is a practical solution to a problem, not a cult we worship.

[Jellied Eel]

Re: I propose a marginally less drastic solution

...the problem is the stack on the users end, which would not work unless updated, and as I said, may as well go ipv6 at this point and avoid the kludge.

In many ways, that's the easy bit. There are/were things that could have been done to extend IPv4, but weren't, eg making more use of the version and option fields. Or even copy v6's mechanism and use option headers. The user's stack is mostly MS or xNIX, which get frequently patched and updated (yes, I can be an optimist), so PCs, servers, phones, consoles etc could eventually get fixed. Except for old stuff, or IoT stuff where the vendor's either gone titsup.com or just stopped maintaining the product. But in those cases, I guess it'd be how often they'd need to communicate with new stuff. If they see a valid header, they'll carry on working.

Or in summary, your proposal may help reduce the need for core network router upgrades, but guess where ipv6 has been running for years? ipv6 is global - apart from the cogent/HE issue, which is purely political, it already spans the world. It's the user end points that are the sticking point, and your kludge does nothing to address that.

I don't think so. The majority of users don't care about the details. I've got a BT broadband connection and they give me an IPv6 address. I don't have to do anything, it just works. Most users don't know or care whether they're using IPv4 or IPv6, as long as they can access pron and cat pics. If their SP doesn't give them IPv6, then any resources that are IPv6-only are obviously unreachable. If they're IPv6 only and need to access the IPv4 world, they'll need a way to translate, or if they're a new business wanting a website, some way for the IPv4 world to reach that.

Despite best efforts, IPv4 isn't going away any time soon, so we need to find ways for the two Internets to co-exist.

[ktm]

Re: I propose a marginally less drastic solution

This is an over-extension of private ip space, just use internal subnetting better and resolve this without increasing complexity with ANOTHER unnecessary protocol.

[Yes Me]

Re: I propose a marginally less drastic solution

You can safely assume that a whole bunch of solutions like that were proposed, analysed, found impractical, and discarded during the design process that led to IPv6. Anything that extends the address size breaks every single existing IPv4 host immediately, so *all* the coexistence and translation problems that we have with IPv4+IPv6 would still need solving. That's why this is hard; it has very little to do with design details.

[Robin Bradshaw]

Musical chairs

Instead of trying to find more ipv4 addresses every year they should be taking them away, we could have an annual lottery style draw to see what range gets deleted that year. A few years of this and people will stop pissing about and switch to ipv6.

[Zack Mollusc]

Odd.

I find it strange that IPV4 has been running out of addresses for twenty years, has run out of addresses ten years ago, and now bitter infighting on a global scale for this scarce resource which is vital for commerce has pushed the price up to an eye-watering $30.

Really?

$30 when streaming companies want $5 for a one-time viewing of a heavily compressed SD resolution version of a fifty year old B movie that is in the dvd bargain bucket at the supermarket?

[doublelayer]

Re: Odd.

Not that unusual. Lots of scarce things are cheap if you look at small quantities. How much does it cost to get twenty liters of water in a desert? Not that much. How much does it cost to have enough water for drinking, cleaning, and agriculture for everyone in a desert? A lot.

You usually can't buy one IP address for your use. You can rent them easily enough, and often it will be difficult to know how much of what you're paying is for the address as opposed to the server or network you're renting with it. When you're buying addresses, the smallest chunk you can usually buy is a /24, or 256 addresses, and that makes a price of $7,640. That's conservative. Current auctions for /24s are showing prices between $10k and $15k. Yes, I could do that, but it's not a small purchase. And yet, 256 addresses is not very many addresses when doing something at scale.

[Hans 1]

The problem is, of course, that many production systems use these IP addresses in production systems, since they are unroutable across the Internet.

IPv6 is the future.

[katrinab]

"IPv6 is the future"

.., and always will be.

Seriously, I've been hearing this since before most people had head of the internet.

[JKnott]

I've been running IPv6 on my home network for almost 14 years. I get a /56 prefix from my ISP, which contains 2⁷² public addresses.

[etonne]

Yes but you only have 8 bits of subnetting so most of that address space isn't useful. In another brilliant move by the IPv6 team, the entire last /64 of the address space is not routable. The reason they did this is so that the MAC address of every device could be in that part but smarter people quickly realized that was a really, really stupid idea. Like so many other things in IPv6 that are still being reworked, broken, respecified, and redisgned. Not to mention that it's completely incompatible with IPv4 despite IPv4 having a "version" field. As these core original design flaws pile up it turns out IPv6 is just a really bad design that nobody wants. Everybody wants more address space, IPv6 is not the way.

[JKnott]

"Yes but you only have 8 bits of subnetting so most of that address space isn't useful. In another brilliant move by the IPv6 team, the entire last /64 of the address space is not routable. The reason they did this is so that the MAC address of every device could be in that part but smarter people quickly realized that was a really, really stupid idea. Like so many other things in IPv6 that are still being reworked, broken, respecified, and redisgned. Not to mention that it's completely incompatible with IPv4 despite IPv4 having a "version" field. As these core original design flaws pile up it turns out IPv6 is just a really bad design that nobody wants. Everybody wants more address space, IPv6 is not the way."

That 64 bits represents the standard subnet size, which everyone gets. You generally get several of them for routing, etc.. For example, I have a /56 prefix from my ISP, which gives me 256 /64 networks. I can route those all I want. Also, you don't have to include your MAC address if you don't want to. Aside from the address space, there were a lot of things that were changed from IPv4 to improve things like performance. Broadcasts are gone, in favour of multicasts. This allows for more focused use. ARP is gone, but then it wasn't originally part of TCP/IP. It was there and used, instead of coming up with something new. With IPv6, that function is now part of ICMP6.

BTW, IPv6 address space is so huge, every person on earth could have over 4000 /48s.

[Nanashi]

Basically none of this is accurate. The whole /56 is routable, you only have 8 bits of subnetting but the entire address space is useful. The standard subnet size is /64 for a few reasons, including SEND and the security benefits of being very sparse. Using the MAC to generate an IP isn't _that_ stupid an idea, but I agree it does have some downsides, but not much stuff does that these days.

It's not completely incompatible with v4. It's compatible in plenty of ways, many of which are actively in use. The remaining incompatibilities aren't a design flaw in v6; if they're a design flaw at all then they're a design flaw in v4. v6 might not be at the absolute unbeatable pinnacle of protocol design but it's not a particularly bad design either.

Over 2 billion people are already using v6, so it does appear to be what people are deploying.

[JKnott]

"Over 2 billion people are already using v6, so it does appear to be what people are deploying."

The 4G & 5G cell networks are supposed to use IPv6, as are VoLTE (4G) and VoNR (5G). My Android phone is IPv6 only and uses 464XLAT to access IPv4 only sites.

[Danny 14]

IPV6 is the future. just not the now. We moved our servers to ipv6 and itnisnt that hard, you juat need to get your head around "you dont nat your servers now" and get a decent firewall.

[I could be a dog really]

Yeah, mostly it's not much more than implementing similar security measures as you do for IPv4 and turning it on/adding AAAA records.

There's still a void around managing multiple uplinks with PA address space. With IPv4 & NAT, you manage that at the network level and can apply policies based on knowledge of link state, capacity, latency, costs, etc. Currently, there is no easy way to manage other than just allowing every endpoint to "randomly" pick which PA space it uses for outbound connections without any knowledge of link state or merits. Not a problem for small users like me at home with only one ISP service, not a problem for those large enough to justify PI space, a bit of a problem for those in between.

Other than that, most of the "looks complicated with IPv6" stuff could also be described as "very difficult or impossible with IPv4".

[Jellied Eel]

Other than that, most of the "looks complicated with IPv6" stuff could also be described as "very difficult or impossible with IPv4".

The reverse is also true. Multi-homing was never really intended for IPv6. Your service provider assigns you a /32 and wishes you the best of luck. There were some good reasons for doing this, mainly to try and keep the routing tables neat in the face of zillions of new IP addresses and potential networks. But multi-homing is also a GoodThing for resiliency, and eventually RIRs conceded and permitted PI IPv6 networks. Providing you jumped through some hoops to get them, and of course pay, and pay to for those addresses to be added to route registeries.

The biggest problem is we now have two Internets, and the protocols are fundamentally incompatible. The idea was everyone would go 'Yey, IPv6!', migrate, and IPv4 could be turned off in a couple of years. That never happened. People started to realise in some ways, it was actually an inferior protocol, especially in some areas that really mattered. Like security, privacy, resiliency. Some of this got compounded with perhaps poor choices, eg picking AAAA DNS records instead of using A6. That makes multi-homing harder than it needs to be because AAAA records are dumb.

There's also other aspects where IPv4 is arguably better. The world converged to Ethernet. Ethernet is a broadcast protocol based on MAC addresses. IPv6 can encapsulate the MAC address, even when you don't really want that exposed. But IPv6 can't do broadcasts. So if you have a LAN for your smoke detectors or fire alarms, the detectors can't broadcast "FIRE!" and you can't get the fire alarms to ring based on that simple broadcast. Instead of a simple, lightweight ARP, IPv6 relies on more complex NDP, mcast, ICMPv6 and some prayers that's all configured and implemented correctly. Complexity almost always breeds insecurity and misconfiguration.

But the big issue wrt addresses is still bridging the divide. So how to get between 4Net and 6Net. There have been various efforts like 6to4, Teredo tunnelling or NAT64.. Which is made more challenging by popular OS vendors treating IPv6 and IPv4 as entirely seperate services. So although it's relatively simple to just tack the 4 IPv4 octets into the last 4 octets of an IPv6 header, chances are those aren't going anywhere. So rather than reducing the need to NAT, IPv6 arguably made the problem worse. This challenge lead to the creation of 64: as a IPv6 block to support NAT64, and releasing blocks in the IPv4 space on the far side. Which I guess is something that could be done with 240/4, ie assigning it to try and make NAT64 or other bridging solutions a little easier.

Most of the problem is still historical. We're stuck with both IPv6 and a US/Western-centric resource model, despite Asia-Pac and the developing world having larger populations and a greater need for IP addresses. And I think commoditisation of address space has compounded that problem. If you have deep enough pockets, you can buy IPv4 networks. If you have a need, justfication and all the good things you're supposed to show to get an assignment. Tough. Even though there is still a lot of IPv4 space that could be allocated and assigned.

[Anonymous Coward]

There is nothing inherently more difficult in calling a multicast rather than a broadcast address.

In addition, there are MANY advantages over ARP: https://superuser.com/questions/969831/why-is-arp-replaced-by-ndp-in-ipv6

As for A6, whilst it could be configured as AAAA, some argued that the extra DNS "reading" work was more of a disadvantage that the potentially less "writing" work.

However, whatever your views, going to AAAA cannot be described as a disadvantage when compared to IPv4. It's still better than IPv4 DNS in that there is far better delegation resolution for PTRs

[JKnott]

"Multi-homing was never really intended for IPv6"

????

It most certainly is. IPv6 supports multiple addresses on an interface. You can also have multiple routers, with a priority assigned, so that if one dies there's another ready to go.

As for broadcasts, the IPv6 equivalent is the all hosts multicast.

[dc396]

Sure, IPv6 supports multiple addresses on an interface. Which source IP address does your application use and how does it find out?

[JKnott]

"Sure, IPv6 supports multiple addresses on an interface. Which source IP address does your application use and how does it find out?"

I don't know all the details, but RFC 6724 covers part of that. Also, as I mentioned, routers can have priority, so that would help choose the best source address.

[Anonymous Coward]

Don't forget, if you really wanted to, there's nothing stopping you using NAT6 on your ipv6 network, so even that argument doesn't work.

[Roland6]

I thought the mobile networks already did this. During lockdown, I had cause to do a deep dive into 4G client addresses and discovered EE were assigning private IPv6 addresses to my devices (both phones and dongles), Three on the other hand were assigning public IP addresses to those with a data plan purchased with a dongle, phone contracts received a private IP address.

Hence why you needed something like A&A’s L2TP-VPN, where your client 4G device initiated the VPN with a public gateway, L2TP being used to provide a lightweight wrapper for the 4G telco network hop, not for end-to-end security.

[JKnott]

"I had cause to do a deep dive into 4G client addresses and discovered EE were assigning private IPv6 addresses to my devices (both phones and dongles)"

My phone is IPv6 only and uses 464XLAT to access IPv4 only sites. It also provides a /64 prefix to tethered devices, so they can use IPv6 too.

[Roland6]

Now try and connect to your phone from the Internet using IPv6, that will confirm whether it is using a public or (more likely) private IPv6 address and thus your carrier is using IPv6 NAT…

[Nanashi]

No it won't. NAT only affects outbound connections, so you'd have to test for it with an outbound connection. You can determine if you're behind NAT by connecting outwards to a remote server, and checking whether the source IP of that connection as seen by the remote server is one of the IPs assigned to your device. (Note that proxying, transparent or explicit, would also change the source IP, but I think/hope that's rare today.)

It's possible to be behind NAT with functioning inbound connections, and also to not be behind NAT but still not have functioning inbound connections. Many mobile networks block inbound connections with a network-level firewall, so the latter is fairly common.

[JKnott]

"Now try and connect to your phone from the Internet using IPv6, that will confirm whether it is using a public or (more likely) private IPv6 address and thus your carrier is using IPv6 NAT…"

While I don't know about my carrier, some block incoming connections. However, I can look in my phone's info and see a real IPv6 address. No need for NAT on IPv6.

[JKnott]

"there's nothing stopping you using NAT6 on your ipv6 network"

Other than blatant stupidity. There is absolutely no reason for any sane person to use NAT on IPv6.

[Jamie Jones]

I was just pointing it out to those who seem to think a NATed network with one external IP is more secure than an inherently p2p ipv6 network.

My point was, if that's their belief, then their argument against IPv6 still falls short, as NAT6 exists too.

[Anonymous Coward]

Or...

Take some of those mega blocks away from Chinacom. You know the ones that send nothing but spam or try to hack your network.

I added a /13 block of addresses for my firewall block list earlier today. In 24 hours 16 different IP's from within that block tried hacking my webserver.

[Anonymous Coward]

Re: Or...

Seeing as China doesn't even want to be part of the p2p internet, remove ALL china blocks, and let them run the entire thing on CGNAT. Hell, they could continue to use the IP addresses they already use, and proxy all external requests.

[BPontius]

Upgrade to IPv6

Wasting so much energy on keeping IPv4 alive, when IPv6 offers 340,282,366,920,938,463,463,374,607,431,768,211,456 of IP addresses. Upgrading to IPv6 offers fewer roadblocks to implementation, in contrast to reversing 41 years of reserved IPv4 addresses. There is no doubt we have to move to IPv6, the millions spent on buying more IPv4 addresses could be spent on infrastructure to move to IPv6.

Sign the DNR on IPv4 and let it die!

[JKnott]

Re: Upgrade to IPv6

I get a /56 prefix from my ISP, which provides 2⁷² public addresses. Some ISPs provide a /48 prefix which is 256x bigger. There are enough public IPv6 addresses to give every single person on earth over 4000 /48s.

[Anonymous Coward]

Re: Upgrade to IPv6

Yeah but won't anyone think of the ISPs? They need to make money selling air to you somehow. /s

[JKnott]

Instead of all this nonsense about extending IPv4, why not just get off the pot and move to IPv6. It's been around for years, I've been using it since May 2010, and is the future. There are a lot of benefits to it, beyond just the unbelievably huge address space. I have a /56 prefix from my ISP, which provides 2⁷² addresses! It was also tidied up a bit from IPv4 to improve certain aspect and improve performance.

[Technogeek]

Anyone not heard of IPv6?

This is just stupid, we have IPv6 which does not have an address space problem, moreover it also addresses many of the fundamental weaknesses in IPv4 which is way beyond the end of its retirement age. IPv6 has been at large on the Internet since IPv6 day in 2000 and here we are 24 years later pissing about with IPv4. Of course there is money to be made in releasing that block of IPv4 addresses so we are never going to junk IPv4 with all the myriad of hacking issues it allows.

[Anonymous Coward]

Re: Anyone not heard of IPv6?

"does not have an address space problem"

Oh god, a massive montage of techies just flashed through my head and this dumb statement tacked on to the end of it all.

"640k is enough memory"

"We'll never need bigger drives"

"You can fit the entire knowledge of mankind on a single CD"

"16GB is loads for gaming"

Argh! My head! I've heard so much of this shit in my lifetime that anytime I hear that something is "enough" in tech, I know it's probably not.

Just like folks that rolled out IPv4 back in the day couldn't fathom the future size of the internet, if we roll out IPv6 today, everywhere, we can't fathom the extent of whatever ends up on top of it.

[Nanashi]

Re: Anyone not heard of IPv6?

Putting some numbers on it, the difference in size between v4 and v6 is the same as between 640 kilobytes and 50 billion yottabytes. 16GB is only 26000x times bigger than 640k, whereas v6 is 80 trillion trillion times bigger than v4. They're just not on the same scale, to the point that it's not reasonable to blindly argue "other things weren't enough so this isn't either".

We certainly can run out if we're stupid (e.g. there's still only 256 /8s in v6), but we can be stupid with any size address space. v6's 128 bits does seem to be large enough to avoid running in maximum-conservation mode if we're not stupid about it, which isn't something you can say about v4.

[ktm]

I can understand this on the one hand, but on the other, tech backend should feel compelled to migrate to IPv6, as I'VE makes the exhaustion of IPv4 insignificant, as well as all of the arguments brought up in this article

[Anonymous Coward]

Oh god.

Imagine that crap that is going to flood in from long forgotten debug code in dev scripts left online if you get one of these IP addresses. Jesus.

[Ken Moorhouse]

Re: Oh god.

Y2k v2.

ISTR Microsoft had some hard-wiring built into their coding.

[Jim-234]

For 2 decades the IPV6 folks have been talking about how it's the best thing and everybody should move to it right away.

They totally ignore the reasons why their great shiny has seen lackluster support.

Security concerns for example are completely brushed aside instead of being actively resolved.

They completely ignore the huge amount of complexity it brings

Privacy concerns are treated as something they won't even consider.

Stupid long addresses that are fine only for folks sitting copying and pasting things.

I'd bet in 20 more years IPV4 or something based on it, is still far more widespread than IPV6

[Nanashi]

None of that stuff is ignored, you're just seeing a serious amount of FUD from people who don't know much about v6, or often networking in general.

The primary security concern I see is "it doesn't have NAT", which is nonsense because NAT doesn't give you any security. The complexity isn't that big, especially compared to v4-in-practice which involves a lot of NAT. The privacy problems are also nonsense given the presence of temporary addresses, RFC7217 and randomized MACs (...and HTTP cookies which are used for the majority of tracking). The addresses are SUPPOSED to be long, that's kind of the point; rather than ignoring it they added AAAA records to DNS and also allowed abbreviating addresses with lots of zeros in them.

All of this has been explained repeatedly, both in comments here and elsewhere.

[Roland6]

NAT, has its uses, hence why it is so pervasive.

I think if IPv6 routers could achieve a similar level of out-of-the-box security by having block inbound connections set as default (which is effectively what NAT achieves).

What is probably more problematic is the hiding of my network. If I use my EE 4G router (ie. an IPv6 device), I am limited by EE as to the number of devices on my LAN who can talk to the internet. Swap the EE router for my own router and use NAT, EE only sees one device …

So I suspect rather than repeatedly saying “ NAT doesn't give you any security”, we need to say this is how to achieve the benefits of NAT in IPv6 and encourage manufacturers to make such settings out-of-the-box defaults.

[JKnott]

"What is probably more problematic is the hiding of my network. If I use my EE 4G router (ie. an IPv6 device), I am limited by EE as to the number of devices on my LAN who can talk to the internet. Swap the EE router for my own router and use NAT, EE only sees one device …"

That's not much of a network. I get a /56 prefix from my ISP, which is 2⁷² addresses. Even my cell phone gets a /64 for tethered devices. No need for NAT, with 18.4 billion, billion addresses.

[Roland6]

Now put your phone in hotspot mode and seen how many devices can connect through it?

As a phone it will probably be limited to 4~6 devices, regardless of IPv6 and getting a /64.

Depending on which EE device I use, their 4G network will limit the number of devices, think small numbers eg 6 or 16 devices; the use of IPv6 makes no difference, however put those devices behind a non EE router and you can happily connect 30+ devices through the router to the EE IPv6 4G network.

[JKnott]

"Now put your phone in hotspot mode and seen how many devices can connect through it?"

I don't think you'll find many networks where there aren't practical limitations on how many devices you can connect, long before you reach the numerical limit. For example, MAC addresses are 48 bits. How many devices can you practically connect?

I normally connect only one device to my phone, so I can't say what the max is.

[Strangelove]

So, comments seem to agree that IP6 has far more addresses than anyone could ever need - so many in fact that every single networkable device I own could have one that was unique on the planet. And of course utterly impossible for me to remember.

As a non network person, neither of those looks like a good thing to me. ..

My ADSL router is 192.168.1.1, and also, very usefully when logged in at there place, so is everyone else's making logging into the thing to set up the firewall something that we have a sporting chance of managing.

Rather like knowing the toilet is upstairs over the kitchen in all the houses built in a given style it saves you having to ask, althhough in most houses the home owner knows where the loo is. they probably do not know the address of their own router

Each house has half a dozen items and they will be 192.168.1. something, and that one 3 digit no can be written on it in crayon if we need to know it for static routing.

as someone who does embedded programming where every byte of RAM counts, to waste two lots of 128 bits in every packet on source and destination seems a waste of RAM, clock cycles and microamps if the thing we want to talk to is on the same LAN anyway.

I suspect that the folk who want IP6 actually want to do things that are more complex, but they are such a small fraction of the total of computer users, that they are outweighed by the rest of us where routing for the backbone and the shortage of non-local addresses is of no interest - so long as the DNS works...

Would a simpler IP5 have caught on? Perhaps IP6 is it a bit like plan 9 one step beyond what is usually needed.

Mike

[JKnott]

"So, comments seem to agree that IP6 has far more addresses than anyone could ever need"

First off, if you want simple addresses, there's nothing to stop you from assigning them. Also, you can always use DNS so that you can access devices by host name. You should be doing that anyway.

We're long past the days when every byte counts and we also no longer have to worry about having sufficient addresses. Sticking with IPv4 means sticking with NAT and that means breaking things. It also means some people will not have a reachable address for use with VPNs etc., because they're stuck behind carrier grade NAT (CGNAT). IPv5 was an experimental streaming protocol that never went anywhere, but parts of it are incorporated into IPv6.

One thing that's driven IPv6 is mobile devices. There simply aren't enough IPv4 addresses to support them. With cell phones, 2 addresses are needed, 1 each for voice calls and for data. For this reason, VoLTE uses IPv6. Some telecom companies have found there aren't enough RFC 1918 addresses to operating their networks, without splitting them into zones. For them, remaining with IPv4 just creates one big mess, where one part of the network is not reachable from another part.

There are a lot of reasons moving to IPv6 is a good idea and none that sticking with IPv4 is.

[doublelayer]

Having more addresses than we could use up sounds like a bad thing to you? The problem we have now is that we're running out, and if we made it a bit larger so that we wouldn't run out for a while, that would be more fragile than just doing it right and pushing the limit far, far away. It's what we've done with most of the limits in our systems when we increase them.

When you're using someone else's network, you can't guarantee they'll all be 192.168.1.1. I've frequently seen 192.168.0.1, 172.16.0.1, 10.0.0.1, and various other /24s in those ranges. It doesn't matter, because if I want to access their gateway, I query my network to get the gateway address and it tells me. I do not need to try any of these when my computer already knows the address. It knows the V6 one too. Open that, copy it into your browser, and pull it up. The same steps you probably already use will still work here.

As for wasting bits in a packet, there are a ton of bytes in many protocols already, but I'm guessing you don't consider them wasted. If you're using WiFi or Ethernet, your network controller is already using and storing plenty of extra data in order to work with them. If storing 128 bits instead of 32 is really causing a problem for your hardware, you likely need to spend a couple pennies on better hardware, because we no longer work in dates where 512 bytes on chip is expected. There are embedded controllers that have small amounts, but they usually aren't running full network stacks and trying to communicate that way.

[MikeBurns]

Are we really running out of IPv4?

I would like to challenge the underlying assumptions expressed in the article and many comments. Assuming we are running out of IPv4 addresses is questionable. According to Geoff Huston's presentation at NANOG90 last week, fewer IPv4 /32 equivalents (around 3 billion) were routed at the end of 2023 versus the beginning of it. In other words, the curves that always run up-and-to-the-right have turned downward. And even without .240 there are still another billion addresses technically available.

The supposition is that this is a result of saturation despite the continued growth of devices connected to the internet. The idea of IPv4 saturation is supported by the reduction of prices for IPv4 on the market, which reduction has now been ongoing for over a year. Prices contain information, a lot of it. The routing table also contains a lot of information, and both of these are matching.

The designers of IPv6 (IPNG at the time) could not have foreseen the evolution of the internet into its client-server, CDN inflected state. Or the impact of NAT and the IPv4 market. We never needed 128 bits.

https://storage.googleapis.com/site-media-prod/meetings/NANOG90/4995/20240212_Huston_Bgp_In_2023_v1.pdf

[JKnott]

Re: Are we really running out of IPv4?

You're missing two important points. There are not even enough IPv4 addresses for all the mobile devices. Cell phones have moved to VoIP (VoLTE, VoNR) and they each need a public address, just for voice and they still need one for data. Also, the rest of the phone system has moved or is moving to VoIP.

Also, NAT breaks things. The first thing I was aware of that it broke was FTP, back in the days when we used command line clients. Lately, it's been things like VoIP and some games. The hack for that is STUN servers, so we have a hack on a hack, just to get around the address shortage.

Of course that 2³² addresses is not entirely usable due to various reserved blocks and addresses lost due to block sizes always being powers of 2.

[Roland6]

Re: Are we really running out of IPv4?

> There are not even enough IPv4 addresses for all the mobile devices.

Does that really matter? We have IPv6 and ways of using IPv4 over the IPv6 carrier service.

Okay it means websites etc probably need to run dual stacks and some way for phones (IPv6 end points) to accept and correctly connect to explicit IPv4 public addresses.

Given the experience of the mobile telcos with 4G/IPv6, perhaps we can expect one of the fixed line ISPs to go IPv6 only, with their router handling the IPv4 over IPv6….

> NAT breaks things.

Depends on what you mean, the original RFC for NAT and the subsequent one for NAPT contain guidance for FTP and ICMP. Okay the solution isn’t elegant etc., but a workable solution was presented. I suspect many of the problems people experienced were more to do with poor implementations of NAT & NAPT (and thus the implementation of the FTP packet header rewriter) although the level of detail in the relevant RFCs does leave much to be desired…

>VoIP

I suggest NAT doesn’t actually break VoIP, it was more the VoIP designers only considering a specific “more purist” view of the Internet and so didn’t concern themselves with designing for NAT and NAPT, even through these technologies would have been widely used in the client environment at the time the VoIP experts were drawing up their RFCs…

> just to get around the address shortage.

NAT did more than this. Remember prior to the ready availability of Internet access, many office networks ran TCP/IP, mostly using the private address ranges (specifically 192.168..). NAT permitted these networks to be readily connected to an ISPs service and gain access to the public Internet. Subsequently, it has made it easy switch ISPs.

From memory, it took a bit of a rebellion for IPv6 to take account of such real world considerations, becoming better because of it.

[JKnott]

Re: Are we really running out of IPv4?

"> There are not even enough IPv4 addresses for all the mobile devices.

Does that really matter? We have IPv6 and ways of using IPv4 over the IPv6 carrier service."

Yes. NAT, etc. are barriers to a seamless service, where one phone can talk directly to any other.

"> NAT breaks things.

Depends on what you mean, the original RFC for NAT and the subsequent one for NAPT contain guidance for FTP and ICMP. Okay the solution isn’t elegant etc., but a workable solution was presented. I suspect many of the problems people experienced were more to do with poor implementations of NAT & NAPT (and thus the implementation of the FTP packet header rewriter) although the level of detail in the relevant RFCs does leave much to be desired…"

I've been around long enough to remember command line FTP clients. That was the first thing I remember being broken by NAT. These days, STUN servers are needed for VoIP and some games to get around NAT. Your solution seems to be hack on hack to get around fixing the problem properly.

"NAT did more than this. Remember prior to the ready availability of Internet access, many office networks ran TCP/IP, mostly using the private address ranges (specifically 192.168..). NAT permitted these networks to be readily connected to an ISPs service and gain access to the public Internet. Subsequently, it has made it easy switch ISPs."

Back in the late 90s, I worked for IBM Canada. At that time, I had 5 public IPv4 addresses, 1 for my own computer and 4 for testing in my work, and NAT was nowhere to be seen. I remember the days before NAT and how things were supposed to work. NAT was simply a means to get around the address shortage and caused other problems in the process.

[gregbo]

Re: Are we really running out of IPv4?

Fortunately, we can go back to the mailing lists where the designers of IPng debated their ideas. [1] [2] As far as 128 bits is concerned, there were arguments that the address space should be large enough to accommodate any imaginable usage, especially because the opportunity to increase the address space again might not come around for a long time, if ever.

[1] https://www.sobco.com/ipng/archive/big-i/index.html

[2] https://mailarchive.ietf.org/arch/browse/big-internet/