systemd and ipv6 – why should it/they not be disabled? Ever?

This article is written on a reverse logic, starting from end and attempting to go towards the beginning, although we are not very clear on where to begin 😉

In the end of the article there is the reference article and direct quote of the error and why it is produced.  To sum it up, logind within systemd produces an error for a user process attempt to start an X session process through an ipv6 connection.  Although our allergic reaction to the fact the author on this article speaks in general about linux and displays a systemd related error, we will bypass this detail for the content’s importance.

error: Failed to allocate internet-domain X11 display socket

Now why does X get compiled with its own networking abilities?  Because “some people” like to get X access to the machine remotely.  A problematic reason on its own, but we are not here to solve all of the world’s problems.  It is systemd complaining because sshd is not working right, it prevents a remote ipv6 connection, but logind is there to make sure that a proper connection is made when it should.  Many other pieces of software have their own parts of ipv6 networking functionalities and abilities.  Hmmm,…… !!!  Scratch …scratch … why should they?  Should they not?

WHOSE PROBLEM IS IPV6 MEANT TO SOLVE?

Yours, mine, … my ISP’s, …..?   It has taken nearly 2.5 decades (since 1998) to transition from ipv4 to ipv6.Is the day ipv4 will be globally terminated and disabled/banned by all servers?  As far as I know there is no foreseeable date for when this can be done, or will it ever.  According to our beloved spyware author, google,com, only 30% of all public servers have ipv6 ability.  The ONLY servers recently found to have ipv6 ONLY ability, are test servers where if you can not reach them, it means you have no ipv6 ability enabled.  A good test for us, we will explain later, or maybe not!

Talk to a teenager with a relatively good aptitude in math, explain to them the scheme of 255.255.255.255 and also explain why this wouldn’t it be enough of addressing, how should we go about it?  I suspect the vast majority would say add another (5th) batch of (0-255) numbers or 2^8 power, and increase the quantity by 250+ times.  For every single ipv4 address there can be now 256 subdomains.  Instead this illogical scheme of an undetermined number of digits, alphanumeric, colons, was devised as a solution.  Few people still today, even networking engineers, can really explain you what does a specific ipv6 address really mean.  Ipv4 addressing scheme, like tel-numbers, made sense to even 12 year olds.  Ipv6 scheme only makes sense to encryption mathematicians.

But was it your problem the internet was running out of IP addresses?  It wasn’t mine.  Did you experience a problem ever, of a dns providing you with an IP that matched two different servers?  No, and no.  So why are we exposing ourselves to connectivity we have little understanding about, vulnerabilities of a different variety than we know how to handle with ipv4, software that provide the ability to directly communicate through an ipv6 channel, but provide unknown protection for having such ability, and software we wouldn’t imagine they had their own networking functionality, that they actually do.  This is a totally different protocol, not an expanded/modified protocol.

Search a bit on how to turn it off and you may get an uneasy feeling of people presenting themselves as experts, offering advise and tricks, not knowing themselves enough on the subject.  The most common solution to turn ipv6 off offered is on the bootloader to add a “ipv6.disable=1”, which tells the kernel to disable all ipv6 functionality.  Does it always work?  No, we have found evidence that it doesn’t, and relies on a non-hardened kernel with sysctl enabled, to pass options to the kernel.  (just yesterday, due to a comment on an article here someone mentioned instantOS and entering this modification to its bootloader didn’t prevent ipv6 functionality).  The other is to edit /etc/sysctl.conf and add 3 lines that disable ipv6.  If the init system’s configuration allows sysctl to the sys-admin this may be somehow effective, otherwise it is udeless.

VERY FEW articles from those experts explain that if you do both the bootloader modification and sysctl.conf modification, the boot process will cause kernel panic.  Why?  Because you are trying to modify something the kernel has forgotten about since the boot loader’s command was issued.  So do the one or the other, but not both.  No, we are no-experts here, just finding out this detail being important to you.

You most likely think that 1 piece of software handles ALL networking through a particular interface it manages.  So if ipv6 is blocked there, there will be no ipv6 connectivity.  Do some more search on ipv6 on the net, you may find that tunneling ipv6 connectivity through ipv4 is quite common and adoptable.  So say a browser, incorporates this ability, when a direct ipv6 connection is blocked somewhere, it transforms the packet to be transported through ipv4, and be reconstructed as an ipv6 connection on the other side of the tunnel.  Ohh.. shit!!  Most security systems, firewalls, really have focused on ipv4 vulnerabilities known since the 70s or discovered since, and just apply the same to ipv6, having done little research for any “new” vulnerabilities that have not surfaced.

How many packages do you have installed that have ipv6 functionality, do you know?  I’ll say many without knowing what you have installed, because in the very core of every linux distribution there are several packages, that unless you configured and build them yourself, ipv6 is ON by default!  What to do about this?  Start with the kernel, the most important functionality provider for all, and search the config for ipv6, disabled it everywhere.  Build your own kernel that is.  Then build from source everything you use, scan and configure ipv6 off.  Still may not be enough or be easy, as for example dhcp/dhclient and other combined server/client software, where the author can’t imagine why you want a server with ipv6 disabled and provides little ability to turn it off (or you can but the build fails).  One interesting such failure was that an array/string whatever inside the code called get_client_id doesn’t exist when ipv6 is turned off.  So the server CAN’T get a client_id unless ipv6 is ON!

The more you try to turn the shit off the more intense the urge to really find out a way to turn it off.  Maybe it is too late down the strip of linux-development to really attempt such a task.  So what does that really mean?

I don’t want to spell it out for everyone, you make your own deductions and assumptions, I make my own and keep them to myself.  For such an extensive adoption of a solution to a non-problem in the open and free software “market”, there has to be a good reason, don’t you think?  Hey, did you know that certain pieces of hardware get their own ipv6 address?  Should I use a cliche, you can check out the matrix but you can never leave?

On the extreme other end of the paranoia spectrum is the case of NetFlix and some other international media vendors, who in the effort to differentiate cost and variety for different markets, are unable to screen through ipv6 connections and VPN proxies, and are blocking ALL ipv6 traffic.  Mostly because some of the material they sell is restricted for physical clients within the continental US, and prevent outsiders from accessing it.  This fact lets us assume, that ever since the initial proposal of ipv6, there was no effort to distinguish country of origin by ip address.  This means for “some” there are many more identifiers hiding within ipv6 the last thing they needed was a country of origin.  Why worry about country of origin when you can have the geolocation of the most remote router providing the connection?

Enough said, do your own research.

source: tuxgraphics.org/npa/disable-ipv6-linux

 

.
.
.

Linux sshd X11 forwarding fails when ipv6 is disabled

sshd has a configuration option called AddressFamily (in /etc/ssh/sshd_config) and many linux distributions set it by default
to “AddressFamily any”. If you disable ipv6 and leave “AddressFamily any” then sshd will still try to work with ipv6 addresses and that causes X11 forwarding (ssh -X …, remote start of graphical applications) to fail. You get this error:

Apr 2 12:53:14 lenie systemd-logind[1430]: New session 201 of user guido.
Apr 2 12:53:14 lenie sshd[372]: error: Failed to allocate internet-domain X11 display socket.

.
.
.