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
For Linux, there's a kernel setting for that.
Just run
so IPv6 will not include IPv4-mapped addresses.https://www.kernel.org/doc/Documentation/networking/ip-sysct...
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.
usually better to set IPV6_V6ONLY in the application itself.
This affects -to my best knowledge- only bind()ing, not outgoing connect()ing. As the name implies, really.
(I should try this, not entirely sure tbh.)
It won't help you though if the resolver library gives you a ::ffff:ma.p.p.ed address (yes they can do that), then you just fail to connect…
I did try this. connect(2) with an IPv4-mapped IPv6 address on an AF_INET6 socket with IPV6_V6ONLY set on it fails.
Very good to know, Thanks for trying!
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.
Reminds me of a time where someone stored the md5 hash of a password as a string by throwing away all non-ascii bytes; so roughly half the bytes.
I've seen something similar, but it depended on whether plain `char` is signed or unsigned, which is highly platform-dependent.
that's the first thing i ever uploaded anywhere! fixtxt.exe on simtel.net
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.
In my personal experience, OpenBSD going against the RFC and being different to everyone else has made more headaches for me.
> OpenBSD (and other OSes)
are there actually other OSes doing this?
(- by default?)
I think of that as the opposite - an IPv6 socket pretending to be IPv4 in order to route to an IPv4 endpoint.
Depends on the vantage point: For a firewall that's ip4 hiding in ip6. For a router, that's ip6 accomodating ip4.
::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.
What a bad faith response.
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?
I learnt this when using net.ListenTCP in Go, if you use lsof to show the network type, it would be IPv6. But it could also handle IPv4 requests.
Still waiting for that bug that was solved by using ipv6, not caused by ipv6
Any bug whatsoever involving NAT traversal?
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.
[1] https://en.wikipedia.org/wiki/6to4
[2] https://en.wikipedia.org/wiki/6over4
It's a mess when you learn there are also 6in4, 6rd and teredo...
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.
And for a short while, it was the most common use of IPv6 on the public Internet! Now largely dead and gone.
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