It's important to emphasize it only changes the default behavior: unprivileged programs can still use setsockopt(..., IPPROTO_IPV6, IPV6_V6ONLY, ...) to override it. That's not a terribly uncommon thing to do, since different distros have historically used different defaults for the sysctl: you'll have to handle it either way.
In a similar fashion, I once saw a python script that called out to a one-page C program that read a .csv dump (probably from SQLServer) and blew away the upper byte of each character, demoting it to ASCII.
Once I understood what was afoot, I was sad that someone had worked so hard when python's open() call supports an 'encoding' argument for just these occasions.
I think OpenBSD (and other OSes) that do not allow v4 on v6 sockets might be on to something. It was felt convenient for application programmers to only have to listen to one socket for two protocols, but then code after needs to make very sure they know how to handle both families in the correct way for logging and so on, and now much later on it confuses someone that has to dig very deep into why the v4-box talks v4 without using v4.
Could be an indication that in the long run, just forcing applications that need both protocols to have separation so you are sure of what they are doing was the correct choice.
::ffff:0:0/96 is for representing v4 addresses in v6 APIs. You shouldn't even see it on the wire at all, but if you do it's just a regular v6 bogon range and not anything to do with v4, so it doesn't get or need any special handling in firewalls or routers.
You need to be a bit careful with terminology, IPv4-compatible and IPv4-mapped are different, i.e. ::/96 vs. ::ffff:0:0/96.
The former (compatible) are not in use anymore, they were specified in an old tunnelling RFC. The latter (mapped) are used for sockets that bind to both IPv4 and IPv6.
There are even more ways to include IPv4 addresses in IPv6 ones (NAT64, 6to4, ...)
>I thought I must have this wrong, surely you can’t just smash an ipv4 address in ipv6 field and magic happens?! Nope, didn’t have it wrong, that’s what happens. Linux supports this, and will go on to route the request as IPv4.
I mean... it's literally one of the officially defined unicast IPv6 address types. If you ever read the Wikipedia page to learn about what link-local, global unicast, etc. addresses are you surely would have seen it.
Not everyone spends their days digging through networking specifications. I for one earned CCENT and CCNA certifications was entirely unaware of this mechanism.
maybe it just means those a pretty worthless certs focused on training you to shill for cisco instead of teaching you actually important network concepts...
No, it means I didn't spend any time on a random specification that will rarely be seen in a production environment. I feel I gained a lot of networking knowledge.
Not sure if you can call it “rarely”; it is very common in application programming. But it is never sent over the wire (unless there is some very buggy IP stack somewhere), which is probably why you did not encounter it in entry-level router/switch certifications.
If you are going to do weird shoot-self-foot things with writing custom EBF scripts to do ill advised network traffic manipulations things then it is probably a good idea to pay attention to RFCs.
I mean I have a small book of notes I built up based on various network RFCs and I am don't even have a CCENT and CCNA certifications.
This sort of thing isn't unreasonable.
Of course this isn't a dunk on the author of the article (except the part about doing weird DNS games, which sounds like a nightmare for whoever needs to figure out what he did months or years from now). Everybody has run into situations were they think they know how something works and it turns out they are wrong and get a nasty surprise from it.
If you are searching for information about IPv6 (as the author of the post was doing for their endeavor) the Wikipedia page will be among the first things you will look at. And if the Wikipedia page clearly states this information then not only is it reasonable to expect someone to find it, but it's very far from "digging through specification"
...the author of the post linked a wikipedia article about the mechanism in their article. That is how they found out about it. What point are you even trying to make?
If you think that's wild, just wait until you learn about 6to4 [1] (not to be confused with 6over4 [2] ...)
TL;DR: Given a globally unique IPv4 address, you can create automatic tunneling IPv6 networks with the IPv4 address embedded into the IPv6 address space.
Out of all of those, 6rd is actually a success, though 6rd is built on top of 6to4. Funnily enough, the first ISP to apply 6rd has actually inverted its network and is now using 4rd to provide IPv4 to some of its customers.
Not just that, but also 4in6 (IPv4 in modern networks) and 4over6 (an extension to DS-Lite), and don't forget 6in4 being called SIT in an early draft, followed by SIIT being used in another protocol with a similar purpose (though that's more of a "Linux kept the old name around while everyone else moved on" problem).
Like most actually-used transition mechanisms, 6rd the result of someone inventing a transition strategy for a very specific use case, a company with that use case actually using that solution, and followed by standardization for good measure.
6to4 has been disabled for a few in Windows and has been disabled by default in Windows 11 since release, so in practice you probably won't see it outside of legacy networks and the routing systems designed to support 6rd or legacy networks.
Teredo was a weird Microsoft thing (like so many other network protocols) that could've replaced stupid shit like STUN and TURN had it been used. I'm pretty sure only Microsoft ever bothered to host Teredo servers to the mainstream. It would've been nice to live in a world where STUN and TURN worked for any protocol without having to set up your own servers rather than just supporting UDP and the server of an ad company (like we use today).
6in4 was a naive attempt at making the transition to IPv6 possible in the very early days (1996). It's the response to all of the "what if we just added a bunch of bits to IPv4" suggestion, and it turns out that nobody who says that actually seriously cares about supporting IPv6.
6in4 is just a basic "put the v6 packet directly into the payload of a v4 packet" tunnelling approach. It's a sensible way of tunnelling one protocol over another (and it's the same thing as 4in6, just the other way around).
HE's tunnels are 6in4, and 6to4 and 6rd are automatically-configured 6in4 tunnels.
pretty cool seeing all the stuff people do to make networks talk, honestly makes me wonder - you think stuff like this sticks around because of habit or just taking shortcuts sometimes
Just run
so IPv6 will not include IPv4-mapped addresses.https://www.kernel.org/doc/Documentation/networking/ip-sysct...
reply