welterde

This is already a thing in IPv6 pretty much. You can write applications IPv6-only and support IPv4 via IPv4-mapped addresses (::ffff:1.2.3.4 for the IPv4 1.2.3.4). The host still needs to be dualstacked for that to work though. In case the host is IPv6-only you can use NAT64 (or similar technologies), where the IPv4-space is embedded behind some other prefix, but the application just talks plain IPv6 and doesn't have to care too much what happens in the background.

The problem is that IPv4 has no provisions to be forward-compatible with anything with a larger address space. Thus whatever replacement you can think of will have the same problems as IPv6.

For applications that were written with X11 in mind it works much much better than that. One example was the controlling a telescope. The computers in the control room were thin clients pretty much and displayed various windows from various machines across the mountain - even across multiple different operating systems! Some machines were running Solaris and some linux. The different machines belonged to different aspects of the telescope: some controlled the telescope itself and some machines belonged to the different scientifc instruments on the telescope. And it all worked quite well with no real noticeable lag.

> For SSH forwarding you could have SSH ask the X server for a new socket for forwarding purposes - so remote clients can't snoop on local clients.

SSH pretty much already does this. Per default (using -X) X11 forwarding is in untrusted mode, which makes certain unsafe X11 extensions unavailable. So remote clients already cannot snoop the whole keyboard input.

Some aspects of the client isolation are used by default when doing X11 forwarding via SSH. A remote keylogger will not work for instance.

IPv6 clients (or in theory any kind of IPv4 successor) can reach IPv4 servers via some kind of translation layer (for example NAT64) - so IPv6 is backwards-compatible with IPv4 in that direction. The inverse direction (IPv4 client to IPv6 server) is however not possible, since IPv4 is not forward-compatible with any possible successor, because it is not possible to encode more information into 32-bit than 32-bit.

Reliability is certainly one aspect where dedicated tracks helps a lot, but is not the only solution (see for example Switzerland). For Germany the issue is the overall too large utilization of the network and the large backlog of required maintenance of the rail infrastructure (in my opinion).

That has very little to do with the ICE train itself though, which can do above 320 km/h just fine in regular service (on international connections though, since in Germany the global train speed limit is 300 km/h I believe).

While the high-speed tracks in Germany are indeed quite a bit of a patch-work, there are over 1000 km of track certified for >= 250 km/h (as of 2015; quite a number of more lines got finished since then, but I could not find the updated number that included them) and by now really rather long corridors are very high-speed. The route from Munich (south of Germany) to Berlin is now mostly covered with upgraded routes for example. I think the 4 hours for that route are quite competitive to Shinkansen times. The fastest Shinkansen route (from the listed operating speed the only one that actually operates at 320 km/h; all others only operate at 260-300 km/h) is the Tōhoku Shinkansen line, which takes 3 hours and 20 minutes for the same distance traveled.

If I read the datasheet correctly you still need an inductor and some passive components externally. The only thing that is not needed is an external switch mode power supply chip.

The X11 primary selection buffer is an even better variant of that though. It allows single-shot copy&paste (meaning only one application can grab it) from the password manager to the target application and it tells the password manager the name of the application that grabbed it.

I think it shouldn't be too hard to hack in a dialog to password managers to confirm if the destination is correct before replying to the data request. But even without that one at least notices that a malicious/wrong application grabbed the password.

Nothing preventing you from writing a X11 server in something else either (and people have done so!). But fact is, most wayland compositors right now are either pure C or C++ (and I think the rest uses at least wlroots?). Many X11 window managers are written in non-c languages too and I don't think I am too far off the mark when I say that a decent fraction of wayland compositors would just be external window managers if there existed a standardized interface for window managers when they were written (I think some compositors have an interface for external window managers now, but is there a standard interface by now?).

It is only one old C codebase however (or a couple if one counts the *BSD semi-forks separately) instead of many different fresh c codebases (one per compositor with some shared code between some of them to be fair). I don't buy that this is actually better for security. It is a lot of more fun/less painful than cleaning up and improving some legacy codebase however.

X11 does have various ways to restrict access (one of which ssh does use for instance) and some more advanced security extensions. But as far as I can tell there has never been that much motivation to widely deploy any of it.

Maybe the problem was with your specific setup or applications? Because at the observatory it worked flawlessly. Between the local data reduction machine (beefy server) and the desktop computer in my office the same. And I used that setup for years and it worked just fine (and I really really hate any lag or glitches).

VNC really sucked on the other hand, not being able to transparently share single windows (at least I never figured out how to), some windows would fail to refresh and I would need to drag them around to get them to redraw, copy and paste was always a pain, sometimes inputs not registering properly.

To be fair to VNC though, over the internet plain X11 forwarding really sucked (latency is the real killer here) and VNC won out there. Unless one was using NX proxy, then it blew VNC out of the water (while using X11 on both ends). Only RDP was somewhat on par with NX over the internet, but locally still beaten by X11.

That's perfectly possible with X11 to attach via VNC to an existing session. But what X11 over (local) network does way better than either RDP or VNC is to run individual applications remotely while having them seamlessly integrate with the rest of desktop. At the observatory for example we were running thin clients in the control room while all the control panel windows were coming from many different machines across the mountain and it felt like all the applications were running locally on the machine in the control room (while in reality nothing was running there).

That is not true. There are extensions to the X11 server that can resolve many of the security issues, but almost no one cares enough to use them.

If you are doing X11 forwarding via SSH it defaults to a more restricted configuration that only allows a more restricted access to the server (no direct sniffing of the input devices for instance).

Not sure having shared memory and socket open to N fresh and under active feature development c codebases is that much more conducive to security? (N since while many compositors use wlroots there is still enough rope to hang yourself). To be fair, unless there is a exploitable bug in wlroots/lower wayland code, the blast-radius will be a lot more limited than if one is found in Xserver.

I think the Qubes approach is the only one worth considering if one deeply cares about security.

There seems to be XACE/XSELinux, which seemingly exists in the mainline Xorg distro now. I wonder how the experience is with that?

In practice I think it doesn't see any adoption, since most people don't run with SELinux or even AppArmor on their desktop and none of the applications run isolated from each other, so it doesn't matter that they all have full access to the X11 server. And for actual security there is qubes, which solves both the application isolation and the X11 security issue.

Only for IPv4 destinations however, where there is no other way. For IPv6 destinations it's just native connectivity with no NAT.

What do you mean it has never been tried? That's how a lot of mobile providers and home internet providers operate today. My provider in Germany was already using DS-Lite (native IPv6 and IPv4 is tunneled over IPv6 to CGNAT gateway) more than 8 years ago. Mobile phones often use 464XLAT where IPv4 is translated to a region of the address space within IPv6 (the backbone is IPv6-only).

The problem is the inverse direction (IPv4 -> IPv6) since IPv4 is lacking any mechanism for forward-compatibility.

That 22k limit is only for the small business rule, which allows the choice of not collecting VAT on sales (but on the flip side cannot deduct it on purchases). Up to a yearly revenue of 0.6M one can also use a simplified profit calculation method for taxes.

There are 2M sole proprietorships in Germany and around 0.4M partnership type companies (Personengesellschaft; GbR, etc.) and aside from the aspect of trying to appear like a large corporation while actually being a small start-up, they are perfectly adequate for many businesses.

There is also no limit on how large a sole proprietorship can grow. While mostly held up as example for why one might not want to keep the company form a sole proprietorship forever, Schlecker scaled from a single shop to over 14000 stores near the end and a couple billion euro revenue per year.

The relevant part is that they moved from another city to Munich, which means that certain company taxes would be paid in Munich instead of Unterschleißheim (the city where the HQ was located previously). This means a increase of tax revenue for the city of Munich of tens of MEUR/yr from this tax alone, without even considering secondary effects.

The small physical distance just means that this would be quite cheap for Microsoft to implement, compared to trying to pull the same stunt with another city.

Because it gets repeated on every thread on IPv6. IPv6 is perfectly backwards-compatible with IPv4 (you can run an IPv6-only host and still access hosts from the IPv4-internet). The issue however is that IPv4 is not forwards compatible. IPv4-only hosts cannot initiate communication with next gen protocol only hosts by design.

Windows actually used to have 6to4 setup by default in the past. There is no need to manually configure anything since the 6to4 have a globally unique anycast address and the ipv6 space is just derived from the own IP address. Of course NAT breaks that if used on some box behind the router (also would break your proposal I think?) and there were a few issues with 6to4 (random people running gateways? who deals with abuse?) that lead to the development of 6rd (and which was used by a few fairly large ISPs).

I have read all of it and I don't agree with you. But lets roll with your interpretation.

Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 connectivity.

All those other things you would still have to take care of even if you magically could keep using the IPv4 address in IPv6 (however that would work). Never mind that servers don't statically sit around forever, but one has to set up new servers all the time.

So why not go for the inverse approach for new servers? Only give the servers IPv6 addresses and for those servers that still need to be reached via the public IPv4 internet (most internal ones probably have no need of this) can be accessed via SIIT, which performs stateless mapping between IPv4 and IPv6 (for example IPv4 1.2.3.4 gets translated to IPv6 2001:db8::1.2.3.4 and vice versa).

I understood djbs article differently then you. What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. Public IPv6 addresses can only exchange packets with each other."?

But maybe I should reread the article a bit more generously and less literally, maybe he is actually advocating for the IPv6 we have today? Because there are transition technologies like NAT64, SIIT, 6to4, 6rd, etc. that sort of allow some of the things he suggested? "If the IPv6 configuration isn't automatic, it won't happen." sounds like he is actually advocating SLAAC to me?

I don't think that plan is feasible at all.

The incentives for vendors to implement it are just not there, since the customer is not actually going to use the expanded address-space feature at all for at least a decade, so why bother implementing it and break the existing stuff in the process? While with IPv6 you could at least somewhat use it right away or at least implement it on the side, where it won't break the existing stuff. And even if you get the vendor to implement it, chances are they are gonna do it the same way IPv6 got implemented initially: By routing it software, so performance is going to absolutely suck. So the first decade after the proposed flag day performance is going to suck until everyone has upgraded their hardware that can do both in hardware.

Next are the random boxes (firewalls or NAT boxes) that will happily mangle all your option bits in the IPv4 header for no reason. Of course while you haven't used any expanded address space everything will seem fine and might even work fine in the lab, but once your flag day arrives and people are supposed to start using it, you will realize it doesn't actually work, because of all those broken boxes in the wild and fun routing bugs and so forth.

And then you get all the regular bugs that come with making any change that were hidden by no one actually using it. You get all the phases IPv6 went through, but much worse and with a couple decades of delay.

The only way to make things work is by using it. The earlier one gets started the better. Wishing really hard does nothing.

No it was not. My claim was that the network address part (the first 64-bit) can be separated into <network>:<site-id>:<vlan>.. etc.

You more or less just reinvented a more complicated variant of 6to4/6rd, which is one of the IPv6 transition technologies.