New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Yes, costs go up and pass that onto the consumer.
The problem is assigning unique IPv4 that existing IPv4 isn't already using.
Isn't 240.0.0.0/16 only 65K addresses? That's solves almost nothing.
I don't think you've technically thought this through. This isn't a solution. I won't go into the three or more things off the top of my head, but saying just give them "the top /32 to be an actual IPv4 address" just caused the worst fucking IP conflict, one done on the other side of the world and not in your own LAN.
The whole fucking problem is adoption and getting people to use it. Nothing above changes that and gives up like a dozen features of IPv6 for no real gain.
Sorry, I had a brain fart when I wrote that. The reserved range is 240.0.0.0/4. I guess I wrote 16 because I was thinking about 16 /8s. Anyway, the reserved space is massive. 268,435,456 /32 addresses to be precise. If you're allocating prefixes to customers as a /40, that's 68 billion, and as a /48 that's over 15 trillion. Just from the reserved range.
No I haven't given it a ton of thought, because there's no point. As you said, we already have IPv6 and such a vanishingly small portion of users care about that, that yet another scheme is never going to be taken seriously.
But, the point is that opening up 240.0.0.0/4 when each larger entity probably only needs a single /32 prefix in that space will last a long time. A large ISP might only need a single address for 64K customers to give them each a /48 prefix. That /48 already gives the customer as much addressing space as an IPv4 and 16-bit port numbers.
There are plenty of other IPv4 ranges that are reserved, and also if a scheme like mine was proposed then pressure on existing IPv4 addresses would be reduced. A low-end host whose users are primarily just going to have a few open ports per machine also might similarly give their customers a /48. Many low-end providers might only need a single IPv4 in this system to replace up to 256 of their current /24s.
I'd be interested to know what these dozen features of IPv6 are that you think are so important, and also what you think precludes them from such a scheme. The only substantive difference is the size of the address space, and that just limits the number of bits that can be wasted at each stage of an addressing scheme.
In truth, the only realistic downside to my idea would be losing the concept of well known ports which aids filtering by type. Such a thing could be done by convention on the lower 12-16 bits.
But, anyway, it should have been obvious by using the term "rant" to describe my idea that I was arguing against IPv6 that has been foisted upon us. I am under no illusions this would ever be taken seriously, given that it's basically 30 years late to the discussion. I do consider it better than IPv6 though, because the jump from 32 bits to 128 bits is excessive.
But anyway, thanks for your valued input. I'll be sure to add it to the criticisms section in a footnote if I ever turn my rant into an actual RFC. Which of course, I won't.
EDIT: I've just had another thought of how to explain this...
The aside on encapsulating over IPv4 and re-using that address space allocation for the /32, you can perhaps think of it as IPv4 with 32-bit port numbers instead of 16-bit port numbers. That's how it might look externally to legacy systems that only know how to forward packets in an IPv4 world, because then the /32 would know how to forward packets to the right place.
The advantage of thinking about it as a single 64-bit address comes from being able to subdivide the prefix length according to site, so e.g. /32 might be ISP, /48 might be customer, /52-56 might be device and /64 service. Customers with many devices may prefer a split favouring more devices. Something like docker container might need a /62 and can just carve out a small chunk of the prefix range that the machine was allocated. Another win is for services like DNS that can resolve to a 64-bit service endpoint without having hacks like port number lookups etc.
But in any case, all this is just in the land of hypothetical, because the industry has decided that we're getting IPv6 whether we like it or not. I still think it's useful to think about alternative approaches that could have been taken, because the thought exercise alone helps develop your analytical brain.
The overall problem is that those ranges are reserved for future use. That means in network code for devices today, they are not supposed to be doing anything with those ranges. It would take software, firmware and silicon (e.g. FPGA's) updates for existing IPv4 devices to suddenly use reserved ranges.
Also,
Some benefits include:
Sure. Defining a new IP protocol seems like a good candidate for "future use".
Not sure why you're mentioning multicast as an argument against what I was saying. This is a separate range, and I wasn't talking about it.
But in any case, basically nothing on the public internet supports multicast nowadays and it's limited to private networks anyway, so sure this is potentially another huge range than could be re-purposed in a new IP protocol without clashing with existing IPv4 addresses.
However, it's kind of irrelevant to this discussion because 240.0.0.0/4 is large enough to provide enough /32 prefixes for a long time, AND as I explained many IPv4 address ranges would be freed up outside the reserved space because the demand for a /32 would drop from per host to 1 per ISP / maybe per company.
Great cut and paste skills rather than actually answering the question I asked, which is what benefits does IPv6 over my hypothetical suggestion? Almost all of these can be implemented just as well with 64-bit addressing rather than IPv6's 128-bit+16-bit port.
All the above would be easy with what I proposed.
I know there are lots of proposals, but I've never heard of anyone actually using this. Happy to be wrong. But again, if it is actually useful, it can still be added to a new IP protocol that used 64 bits. Personally, I don't see the value of another pseudo-random field rather than just using the source/destination pair as a unique key. My hot take on this is that the field is only useful because 2x128 + 2x16 bits is too large to be used easily as a unique key, and that 2x64-bits as a unique key is much more manageable.
Again, you're conflating the idea of IPv6 as all the features defined by all the optional extensions, which can be encapsulated in additional optional headers in any other proposed protocol too, with my central complaint of IPv6 - that 128 bits plus 16 bits for port is excessive, and 64-bits is more than sufficient for foreseeable future needs.
I actually don't see anything wrong with DHCP. In fact, I'd say a benefit of IPv4 is "Easier administration (no more NDP)".
And finally, this shows to me that you didn't read what you copy pasted or what I was arguing. The entire point of what I was saying was that the 64-bit addresses are endpoint focused. There would be no port forwarding, because there are no ports to forward. It'd be packet forwarding based on address. There's no reason why a machine can't have multiple prefixes, just as you'd do with IPv4 or IPv6 currently.
Anyway, as I said before, this was a "rant" about how IPv6 addressing is excessively wasteful and how and we could have come up with something less wasteful that still hits the same goals. There's no point continuing to discuss it further, given that for better or worse, IPv6 has been decided on as the way forward. (Although the fact that 30 years later adoption is still mostly only done begrudgingly doesn't point to it being a huge success IMHO.)
There’s a lot of truth in what @jsg pointed out — the IPv4 shortage is largely the result of historical allocation practices, not necessarily a technical limitation. If IPv4 addresses had been distributed more fairly and efficiently from the start, we likely wouldn’t be in this situation today. Even now, with some political will and technical adjustments, millions of routable IPv4s could be reclaimed or reassigned.
And all the hype about a new protocol began way before NAT was a thing, well almost but Computing power was.
Timeline Perspective
In short, yes — the industry started talking about the "next-generation IP protocol" before NAT even became widely used, and way before it reached consumer hardware. But back then, computing power and deployment mechanisms weren’t yet ready to make IPv6 practical.
In other words, as usually all shit their pants before putting things on paper, analyze it and think, a bit.
On the Need for Unique IPs
Not every device needs a public IP. In a typical household with 5–10 connected devices, NAT with private IP ranges works just fine. Even in larger setups like campus networks, not every device needs to be directly reachable from the internet.
However, certain use cases do require unique public IPs:
Let’s also not forget: a single IPv4 address can now host thousands of websites, thanks to name-based virtual hosting and SNI + Reverse Proxy. That wasn’t the case in the early days of the web, where each site often required a separate IP, and each PC, Printer had a uniqe Public IP, what a mess that was, sincerely.
Oh, this will raise all the shitty corruption practices not years but decades of every RIR. And RIRs don't want it to be visible. RIRs are trying to save current status quo, IMHO.
Mainly agree with you @host_c and @jsg.
:facepalm:
I have an eye appointment on Tuesday. I expect it's time for glasses, I can't see/read like I used to.
I have never personally used QoS before (in useful practice) , but I imagine it's going to be even more important in WiFi, or 5G services. Latest headline in WiFi 8 was focusing on low latency and reliable communications...
It's probably used for cable networks with TV service.
(can) Causes IP conflicts. Runs out of range.
My bad. I thought you were trying to keep IPv4 around forever by extending it instead of replacing it. And when going through the hassle, why half ass it.
I'm not sure why the complaint about wastefulness is an issue. Numbers are free. The number one problem with IPv4 was not enough. That's solved like a motherfucker. Imagine taking decades to replace it and then running into the same issue.
The adoption is slow because NAT took out the urgency and VOIP and end to end communications are still in the hands of big tech. The videos from 30 years ago used end to end video conferencing in the kitchen to talk to your mom to make dinner, not FaceTime.
Years ago during one of these IPv6 threads, someone posted the RFC discussion where 64-bit addressing was proposed and I forget the rationale why, but there were technical responses to it. Since neither cares enough to keep this going, we'll leave it there.