> Who owns all these new addresses? You do. If you own an IPv4 address, you automatically own the entire 96‑bit subspace beneath it. Every IPv4 address becomes the root of a vast extended address tree.
Huh:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
> It's possible they managed to do some rudimentary multitasking with DESQview (or worse...) and so supported two whole users with each box. Does that mean they had to be at least 386s to do protected mode? Or was it virtual 8086 mode? I (fortunately) have forgotten the finer points of how that stuff used to work. I DO remember how damn crashy a box became when you ran it "under DV". Constant system freezes. Yep.
I don't recall DESQview to be all that crashy. I was aware of a number multi-line BBSes that used it (just in the 416). Some BBS software called out its use specifically:
DESQview was absolutely not crashy. I ran several different types of BBS software in it without issues. The "DESQview (or worse...)" comment raised the hair on the back of my neck. DESQview was revolutionary at the time and I was annoyed at having to use Windows many years later.
ASCII windows may not have been everyone's cup of tea but I loved it.
I recall running Opus (or maybe the predecessor whose name escapes me) under DESQview on my lousy XT clone. I don’t recall it being crashy but it certainly didn’t have enough horsepower to handle the BBS software and an interactive DOS window.
I couldn’t afford a second machine in those days and having to sacrifice my one and only PC for the full-time BBS wasn’t fun :)
I used DESQview with my BBS. It only had one line but I ran a second local node so I could be online at the same time as my users. I don't remember ever having any problems with it.
> The IPv4 32-bit address space should have been included in the IPv6 address space, instead of having 2 separate address spaces.
Like
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
> Who owns all these new addresses? You do. If you own an IPv4 address, you automatically own the entire 96‑bit subspace beneath it. Every IPv4 address becomes the root of a vast extended address tree. It has to work this way because any router that doesn’t understand IPv4x will still route purely on the old 32‑bit address. There’s no point assigning part of your subspace to someone else — their packets will still land on your router whether you like it or not.
So the folks that just happen to get in early on the IPv4 address land rush (US, Western world) now also get to grab all this new address space?
What about any new players? This particular aspect idea seems to reward incumbents. Unlike IPv6, where new players (and countries and continents) that weren't online early get a chance to get equal footing in the expanded address space.
If it became universally adopted, then there wouldn't be much need for owning crazy amounts of ipv4 addresses, so the price of addresses would drop. If this proposal was not adopted universally, then we would be pretty much in the same situation as we are with ipv4 addresses
> The new players would each get a /24 and everyone would say that's "enough".
From where?
All then-existing IPv4 addresses would get all the bits behind them. There would, at the time, still be IPv4 addresses available that could be given out, and as people got them they would also get the extend "IPv4x" address associated with them.
But at some point IPv4 addresses would all be allocated… along with all the extended addresses 'behind' them.
Then what?
The extended IPv4x addresses are attached to the legacy IPv4 addressed they are 'prefixed' by, so once the legacy bits are assigned, so are the new bits. If someone comes along post-legacy-IPv4 exhaustion, where do new addresses come from?
You're in the exact same situation as we are now: legacy code is stuck with 32-bit-only addresses, new code is >32-bits… just like with IPv6. Great you managed to purchase/rent a legacy address range… but you still need a translation box for non-updated code… like with CG-NAT and IPv6.
So under this IPv4x proposal one gets an IPv4 /24, and receives a whole bunch of extended address space 'for free'.
But right now you can get an IPv4 /24 (as you say), but you can get an IPv6 allocation 'for free' as we speak.
In both cases legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the IPv4x and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
Essentially.I imagined this hypothetical happening decades ago when there were still a few /8s unallocated. I suggested that those would be set aside for IPv4x only.
Yeah, and the value of IPv4 address space would plummet, and there would be no reason for any company to own a /8. Clawing back address space would involve a few emails and a few months to get network configs ready.
> In a nutshell, an IPv4x packet is a normal IPv4 packet, just with 128‑bit addresses. The first 32 bits of both the source and target address sit in their usual place in the header, while the extra 96 bits of each address (the “subspace”) are tucked into the first 24 bytes of the IPv4 body. A flag in the header marks the packet as IPv4x, so routers that understand the extension can read the full address, while routers that don’t simply ignore the extra data and forward it as usual.
So you have to ship new code to every 'network element' to support IPv4x. Just like with IPv6.
So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (And their DNS idea won't work—or won't work differently than IPv6: a lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "AX" address (for ipv4X addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.
A single residential connection that gets a single IPv4 address also gets to use all the /96 'behind it' with this IPv4x proposal? People complain about the "wastefulness" of /64s now, and this is even more so (to the tune of 32 bits). You'd probably be better served with pushing the new bits to the other end… like…
If you put part of the address in the body space, you can't encrypt the entire body.
IPv6 adoption has been linear for the last two decades. Currently, 48% of Google traffic is IPv6.[1] It was 30% in 2020. That's low, because Google is blocked in China. Google sees China as 6% IPv6, but China is really around 77%.
Sometimes it takes a long time to convert infrastructure. Half the Northeast Corridor track is still on 25Hz. There's still some 40Hz power around Niagara Falls. San Francisco got rid of the last PG&E DC service a few years ago. It took from 1948 to 1994 to convert all US freight rail stock to roller bearings.[2] European freight rail is still using couplers obsolete and illegal in the US since 1900. (There's an effort underway to fix this. Hopefully it will go better than Eurocoupler from the 1980s. Passenger rail uses completely different couplers, and doesn't uncouple much.)[3]
should also bring to mind that there's a technological leapfrogging effect in stages of development which it seems clear that China has taken advantage of.
Yes, I was wondering if I was missing something reading the hypothetical: This is still splits the Internet into two incompatible (but often bridged etc.) subnetworks, one on the v4, one on the v4x side, right?
It just so happens that, unlike for v6, v4 and v4x have some "implicit bridges" built-in (i.e. between everything in v4 and everything in v4x that happens to have the last 96 bits unset). Not sure if that actually makes anything better or just kicks the can down the road in an even more messy way.
> everything in v4x that happens to have the last 96 bits unset
That's pretty much identical to 6in4 and similar proposals.
The Internet really needs a variant of the "So, you have an anti spam proposal" meme that used to be popular. Yes, it kill fresh ideas in the bud sometimes, but it also helps establish a cultural baseline for what is constructive discussion.
Nobody needs to hear about the same old ideas that were subsumed by IPv6 because they required a flag day, delayed address exhaustion only about six months, or exploded routing tables to impossible sizes.
If you have new ideas, let's hear them, but the discussion around v6 has been on constant repeat since before it was finalized and that's not useful to anyone.
I feel like the greatest vindication of v6 is that I’m reading the same old arguments served over a quietly working v6 connection more often than not. While people were busy betting on the non-adoption of v6, it just happened.
This wasn't a proposal, but an alternate history. The world where the people who wished for IPv4 but with extra address space get their way. By the end I come down on being happy with we're in the IPv6 world, but wishing interoperability could be slicker.
> It just so happens that, unlike for v6, v4 and v4x have some "implicit bridges" built-in (i.e. between everything in v4 and everything in v4x that happens to have the last 96 bits unset).
See perhaps:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
As I recall, 6to4 worked beautifully between 6to4 nodes in the absence of middlebox interference. The fatal flaw was the anycast address for accessing the "real" IPv6 network. The rosy outcome imagined in the article doesn't require a hypothetical IPv4 extension: just the novel idea of leaving the IPv4 core alone and extending the edge - which would have brought the financial incentives into alignment.
It's not automatic, there were many proposed and utilized mechanisms for autodetecting translation servers and so on. By now though, if you want IPv6, you order real IPv6, and don't need some translation.
There was no upside for an ISP to operate a 6to4 relay, so the anycast address was worse than a blackhole route. It would occasionally permit a connection, but mostly just caused timeouts. Without that poison pill, it could have been a nice way to allow for connecting private subnets that otherwise use conflicting RFC1918 subnets. That's what I used it for.
Two 6to4 networks will communicate directly between each other without using a relay, so it will still work for that. Although you ought to be able to use native v6 these days.
If you can't deploy v6 (whether native or 6to4) on the remote side for whatever reason, NAT64 is useful for dealing with conflicting RFC1918. You map each instance of RFC1918 you need to access into different v6 /96s, and then they don't conflict from your perspective. (But like NAT44, it only works for outbound connections; inbound ones need a port forward.)
Yes, but the compatibility is very very easy to support for both hardware vendors, softwares, sysadmins etc. Some things might need a gentle stroke (mostly just enlarge a single bitfield) but after that everything just works, hardware, software, websites, operators.
A protocol is a social problem, and ipv6 fails exactly there.
What stymies IPv6 is human laziness more than anything else. It's not hard to set up. Every network I run has been dual stack for 10 years now, with minimal additional effort. People are just too lazy to put forth even a minimal effort when they believe that there's no payoff to it.
> What stymies IPv6 is human laziness more than anything else. It's not hard to set up.
I think the biggest barrier to IPv6 adoption is that this is just categorically untrue and people keep insisting that it isn't, reducing the chance that I'd make conscious efforts to try to grok it.
I've had dozens of weird network issues in the last few years that have all been solved by simply turning off IPv6. From hosts taking 20 seconds to respond, to things not connecting 40% of the time, DHCP leases not working, devices not able to find the printer on the network, everything simply works better on IPv4, and I don't think it's just me. I don't think these sort of issues should be happening for a protocol that has had 30 years to mature. At a certain point we have to look and wonder if the design itself is just too complicated and contributes to its own failure to thrive, instead of blaming lazy humans.
> People are just too lazy to put forth even a minimal effort when they believe that there's no payoff to it.
For me just disabling IPv6 has given the biggest payoff. Life is too short to waste time debugging obscure IPv6 problems that still routinely pop up after over 30 years of development.
Ever since OpenVPN silently routed IPv6 over clearnet I've just disabled it whenever I can.
This goes the other direction too. I just this second fixed a problem with incredibly slow SSH connections because a host lookup which returned an IPv4 address instantly was waiting 10+ seconds for an IPv6 response which would never come.
Now I'm sure I can fix DNSmasq to do something sensible here, but the defaults didn't even break - they worked in the most annoying way possible where had I just disabled IPv6 that would've fixed the entire problem right away.
I'm confused by the argument that replacing equipment is something that is always possible. It doesn't matter that it's easy to support by updating or replacing the hardware - a lot of hardware isn't going to be updated or replaced.
ISPs are used to this though, and tunnel a lot of packets. If you have DSL at home, your ISP doesn't have a router in every edge cabinet - your DSL router sets up a layer-2 point-to-point tunnel to the ISP's nearest BRAS (broadband remote access server) in a central location. All IP routing happens there. Because it's a layer-2 tunnel it looks like your router is directly connected to the BRAS, even though there are many devices in between. I don't know how it's done on CATV and fiber access networks.
If an ISP uses an MPLS core, every POP establishes a tunnel to every other POP. IP routing happens only at the source POP as it chooses which pre-established tunnel to use.
If an ISP is very new, it likely has an IPv6-only core, and IPv4 packets are tunneled through it. If an ISP is very old, with an IPv4-only core, it can do the reverse and tunnel IPv6 packets through IPv4. It can even use private addresses for the intermediate nodes as they won't be seen outside the network.
No, in this hypothetical, routers that don't know about IPv4x will still route based on the top 32 bits of the address which is still in the same place for IPv4 packets. If your machine on your desk and the other machine across the internet both understand IPv4x, but no other machines in the middle do, you'll still get your packets across.
Well no, all the routers on your subnet need to understand it.
So let’s say your internet provider owns x.x.x.x, it receives a packet directed to you at x.x.x.x.y.y… , forwards it to your network, but your local router has old software and treats all packages to x.x.x.x.* as directed to it. You never receive any medssagea directly to you evem though your computer would recognise IPv4x.
Your local machine isn't on the IPv4 internet if it doesn't have a globally routable IPv4 address.
Your home router that sits on the end of a single IPv4 address would need to know about IPv4x, but in this parallel world you'd buy a router that does.
> And it can still send outbound to a v4x address that it knows about.
No, it cannot, if there is a router on the way that is unaware of v4x, it will interrupt the signal.
Say your router is 1.2.3.4.0.0 in IPv4x (and 1.2.3.4 in IPv4). You are 1.2.3.4.0.1 . Someone sends you a message from outside. Your router only sees the previx of the address (1.2.3.4), and since it thinks it has 1.2.3.4, it reads the message and doesn't forward it further.
you are missing the point - updating "network elements" was never the problem. Linux kernel has IPv6 support since 2.6. RedHat got IPv6 in 2008. Nginx got it in 2010. And yet there plenty of IPv4-systems out there. why?
Software updates scale _very well_ - once author updates, all users get the latest version. The important part is sysadmin time and config files - _those_ don't scale at all, and someone needs to invest effort in every single system out there.
That's where IPv6 really dropped the ball by having dual-stack the default. In IPv4x, there is no dual-stack.
I upgrade my OS, and suddenly I can use IPv4x addresses... but I don't have to - all my configs are still valid, and if my router is not compatible, all devices still fall back to IPv4-compatible short addresses, but are using IPv4x stack.
I upgrade the home router and suddenly some devices get IPv4x address... but it is all transparent to me - my router's NAT takes care of that if my upstream (ISP) or a client device are not IPv4x-capable.
I have my small office network which is on the mix IPv4 and IPv4x addresses. Most Windows/Linux machines are on IPv4x, but that old network printer and security controller still have IPv4 address (with router translating responses). It still all works together. There is only one firewall rule set, there is only one monitoring tool, etc... My ACL list on NAS server has mix of IPv4 and IPv4x in the same list...
So this is a very stark contrast to IPv6 mess, where you have to bring up a whole parallel network, setup a second router config, set up a separate firewall set, make a second parallel set of addresses, basically setup a whole separate network - just to be able to bring up a single IPv6 device.
(Funny enough, I bet one _could_ accelerate IPv6 deployment a lot by have a standard that _requires_ 6to4/4to6/NAT64 technology in each IPv6 network... but instead the IPv6 supporters went into all-or-nothing approach)
> Software updates scale _very well_ - once author updates, all users get the latest version. The important part is sysadmin time and config files - _those_ don't scale at all, and someone needs to invest effort in every single system out there.
With IPv6 the router needs to send out RAs. That's it. There's no need to do anything else with IPv6. "Automatic configuration of hosts and routers" was a requirement for IPng:
When I was with my last ISP I turned IPv6 on my Asus router, it got a IPv6 WAN connection, and a prefix delegation from my ISP, and my devices (including by Brother printer) started getting IPv6 addresses. The Asus had a default-deny firewall and so all incoming IPv6 connections were blocked. I had do to zero configuration on any of the devices (laptops, phones, IoT, etc).
> I upgrade my OS, and suddenly I can use IPv4x addresses... but I don't have to - all my configs are still valid, and if my router is not compatible, all devices still fall back to IPv4-compatible short addresses, but are using IPv4x stack.
So if you cannot connect via >32b addresses you fall back to 32b addresses?
> I upgrade the home router and suddenly some devices get IPv4x address... but it is all transparent to me - my router's NAT takes care of that if my upstream (ISP) or a client device are not IPv4x-capable.
A French ISP deployed this across their network of four million subscribers in five months (2007-11 to 2008-03).
> There is only one firewall rule set, there is only one monitoring tool, etc... My ACL list on NAS server has mix of IPv4 and IPv4x in the same list...
If an (e.g.) public web server has public address (say) 2.3.4.5 to support legacy IPv4-only devices, but also has 2.3.4.5.6.7.8.9 to support IPv4x devices, how can you have only one firewall rule set?
> So this is a very stark contrast to IPv6 mess, where you have to bring up a whole parallel network, setup a second router config, set up a separate firewall set, make a second parallel set of addresses, basically setup a whole separate network - just to be able to bring up a single IPv6 device.
Having 10.11.12.13 on your PC as well as 10.11.12.13.14.15.16 as per IPv4x is "a second parallel set of addresses".
It is running a whole separate network because your system has the address 10.11.12.13 and 10.11.12.13.14.15.16. You are running dual-stack because you support connection from 32-bit-only un-updated, legacy devices and >32b updated devices. This is no different than having 10.11.12.13 and 2001:db8:dead:beef::10:11:12:13.
Wouldn't this proposal not require isps to do anything? They already assign every user a unique ipv4 address. Then, with this proposal, if I want to have a bunch of computers behind that single ipv4 ip, I could do it without relying on NAT tricks
> Wouldn't this proposal not require isps to do anything? They already assign every user a unique ipv4 address.
The reason there's an IPv4 address shortage is because ISPs assign every user a unique IPv4 address. In this alternative timeline, ISPs would have to give users less-than-an-IPv4 address, which probably means a single IPv4x address if we're being realistic and assuming that ISPs are taking the path of least resistance.
As long as IPv4x support was just something you got via software update rather than a whole separate configuration you had to set up, the vast majority of servers probably would have supported IPv4x by the time addresses got scarce.
However, if it did become a problem, it might be solvable with something like CGNAT.
CGNAT would also be easier on routers too, since currently they need to maintain a table of their port being used to the destination ip and port. Whereas with ipv4x, the routing information can be determined from the packet itself and no extra memory would be required
That's only true when forwarding IPv4x -> IPv4. When you're going the reverse direction and you need to forward IPv4 -> IPv4x, well, still need a table then.
IPv6 is a parallel system. It exists with IPv4. You don't need to stop using IPv4 - ever - if you don't want to. You can have both the chicken and egg together as long as is needed.
> Voice is everything. Don't relinquish the best part of yourself.
One observation I ran across on the use of the em-dash ("—") was that if AI was given training data from writers that were considered good/great, and those writers tended to use em-dashes, then it would be unsurprising that AI 'learned' to use the character.
So the observer said humans should, if they already did so in the past, continue to use the em-dash now and going forward if it was already part of their 'personal style' in writing.
I've written multiple books, the most recent in 2019. I used to love the em-dash, and considered it the superior form of ellipsis (over the parenthesis, comma or semicolon).
I'm not planning on writing new books now, but if I did, I would completely get rid of em-dashes, because of their second-order effect of making the copy AI-written (and therefore less valuable).
It's also interesting that using a Skill that discouraged the use of em-dashes, I noticed that Claude's "thinking" internal dialogue actually disagreed with the Skill spec itself ("no, actually, em-dashes are perfectly normal and not a sign of AI writing") and therefore kept the dashes, against the Skill instructions.
> The number of overlapping iPad models and variants, for example, is getting kind of crazy these days.
Sort of, maybe (not)?
First off there is the "mini", which is basically if you want a small screen / most portability.
After that, the two questions you need to ask are "How much horsepower and storage do you need/want?" (plain vs Air/Pro), and then "How fancy of a screen do you want/need?" (Air vs Pro):
Do I want an iPad Air or Pro? Both seem pretty thin. Why is it called 'Air'. What am I not getting with the Air? When was the last time each product was updated, since I remember a time when different models were updated at different times (and I never updated my internal barometer if this changed)?
Further, I see older versions of the iPhone on display at the apple store. Does this mean I'm potentially browsing an older version of the iPad?
To be fair, there was some overlap in the Jobs apple store days (when the Santa Rosa processor dropped on the MBP and you didn't know if you were getting the older model unless you asked), but it was never this bad. You had the iPad, then the iPad 2. iPhone 4->4S->5. I don't know how the 'Air' slots in between the regular and the Pro, and I don't know if I'm seeing an older model on display. The whole thing is very confusing.
> Do I want an iPad Air or Pro? Both seem pretty thin. What am I not getting with the Air?
Horsepower (M5 vs M4), display ("XDR brightness: 1000 nits max full screen, 1600 nits peak (HDR content only"; "ProMotion technology"), option for more storage (2TB).
> Laptops also now fall into the trope of good/better/best with Neo/Air/Pro.
...until the bestest Ultra launches, as GP pointed out?
(Also Air used to be 'the light one', not the standard/middling one on same spectrum.)
We could say a similar thing with the Dell names above, the point is that it's confusing to work out which you need/want when there's so many, not that they don't fall in some sort of order across a line from mediocre to best.
> The resulting CO2 is relatively pure, and it's already captured. You can feed it into anther process (such as Urea) or sell it for carbonisation of drinks.
Makes for a pretty good refrigerant as well (R-744):
Huh:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
* https://en.wikipedia.org/wiki/6to4
reply