Follow the guide below, I can make my PC prefer IPv4 over IPv6 by modifying the registry key.
Guidance for configuring IPv6 in Windows for advanced users
Now I want to implement the same function on the router to let all the devices in the LAN prefer IPv4 over IPv6.
This topic shown how to forbid DNS to return IPv6 AAAA records, but I cannot access to IPv6 domain anymore.
The easiest way is probably to use ULAs instead of global IPv6 addresses since many devices prefer IPv4 over IPv6 ULA.
If you want to use global IPv6 address on the device then I think it requires support for RFC7078.
The IP address (family) is chosen by the individual clients, the router is not involved in that step and can't simply rewrite IPv6 addresses as IPv4 for your network. The typical implementation on operating system resolvers prefers IPv6 over IPv4, according to the standards - this is normal and shouldn't be a problem, if it is, the underlying causes need to be fixed anyways.
I'd like to double down on @slh's answer. If you are getting broken IPv6 from your ISP then disable it at the WAN side (and consider getting yourself a working tunnel)... If you are getting working IPv6 you should be preferring it.
Short answer. Don't!
The better question for all of us interested, why do you want to prefer IPv4 over IPv6? As mentioned above, if something is wrong with IPv6, fix the underlying problem, rather than working around it. Short of removing any IPv6 connectivity from a client, forcing IPv4 will be a fun game that not all clients will even honour either, which at this point we have to ask, why?!
with ipv6 global address we can cross ISP's multi level C class network, ex. we have no public ipv4 adress in china, only 100.83.xxx.xxx .
but like pan.baidu.com, dns return both ipv6 and ipv4, the bad news is that the ipv6 cant work like normal, prefer ipv4 then ok.
there is something wrong at the server not me, but i also need to access it.
Why?
We all have our reasons. And there are various ones.
Why do you give answers like this?
I was just googling around and found this thread from over two years ago... and it has no useful reply. Not one. None at all.
I'll give you a few reasons:
I could go on...
So, here I am, with the same question, of how I can make IPv4 networking be the preferred connection type, for connections originating from applications and services that are running on the router in OpenWRT.
Specifically, what I want is that things like DNS resolvers, Stubby, dnsmasq, opkg, and the like, connect over IPv4 by default, even if DNS returns both A and AAAA records, without having to mess with these records.
The correct answer would be to provide the equivalent of /etc/gai.conf or /etc/nsswitch.conf for OpenWRT like you can find for other Linux distributions: https://serverfault.com/questions/93717/
Or to point out, that the OpenWRT implementation has bugs, and that it essentially doesn't work right, because applications like wget don't respect it: Howto make OpenWrt RFC6724 compliant? - #4 by tsunulukai (this may have changed since)
And if you represent the position, that doing something is bad, you can still explain how to do it, explain why you think it is bad, instead of just saying "don't do it", because that is not helpful.
IPv6 is not new. It's been around for over 25 years. I had native IPv6 running 20 years ago.
I would second this. If your ISP is unable to implement IPv6 properly choose another ISP but don't blame the protocol.
Afaik it is not possible to prefer IPv4 over IPv6 because rfcs define that V6 should be preferred if available and Linux follows this behavior.
Btw I would say this is just false. Have a look at the development of ipv4. It is just a clusterfuck and literally escaped the lab without supervision. Ipv4 is full of ugly hacks because it was an experiment which, again, escaped the lab. Ipv6 however is more or less well defined. I will not argue that everything related is roses and sunshine but the protocol on its own is at least planed as a whole and not plumbed together over 30 years.
Also, IPv4 is by no means simpler. Just because many people live happily with there generell ignorance and are even unable to build proper ipv4 networks does not make ipv6 more complicated or difficult. I find it for myself far more easier to design and build an IPv6 only network.
And shit which breaks gets IPv4 on top of that because: it is no magic to transport IPv4 traffic on an IPv6 only backbone. But this old men's gets angry again and starts the grumble and ranting so I will stop at this point.
True, but so is the fact that the internet backbone is not running invariable IPv6... (think MPLS). I accept that IPv6 is clearly here to stay, and that IPv4 has run out its "growth-potential" so we have what we have. IPv6 is IMHO not better or worse the IPv4 in general, both where ratified too early with some experimentation still outstanding and hence unresolved issues. But IMHO that is really irrelevant, we reached the end of the rope for IPv4, without being able to serve/reach all devices we want/need, so it is either IPv6 or something new...
BTW, I do not consider the half-backedness of either IP protocol a showstopper, both work reasonably well (IPv6 introduction made a few mistakes, just like IPv4's initial and on-going development).
I think this is a feature request for the caching DNS server used by OpenWrt:
dnsmasq already has two options to block IPv4 and/or IPv6 answers from the upstream server (--filter-A and --filter-AAAA). Now, what seems to be needed here, is an option to filter AAAA records, but only when an A record has been received.
I would move this thread to a feature request on dnsmasq's site.
This at least reasonable workaround in case the upsteam IPv6 is bonkers. But i would still recommend to find a better ISP or use a tunnel broker or rent an VM and terminate the IPv6 there...
Ps: @moeller0, true. With 6over4 I wanted to refer to local deployments like in business or enterprises but not the Internet in general. But maybe we will see this sooner or later even at IXP and skip the overhead which mpls brings. Announcement of v4 prefixes on v6 peers and route via v6 hops is nowadays only a config flag therefore I hope this will be take place.
That may be what would resolve the OP's request, but it would not resolve the issue I was having.
Specifically, what I would need is configurability akin to /etc/gai.conf on glibc based systems on musl based systems like OpenWRT, such that an API call to getaddrinfo() respects the configured priority order specified.
For me an interesting issue cropped up, wherein, if the OpenWRT system has a non-local IPv6 address configured on any WAN interface, but that same interface has no gateway or the gateway isn't reachable, but the IPv4 network is working properly, then the system's connectivity for DNS lookups and downloading packages (even with an entry in the hosts file for the package server's IPv4 address) ends up effectively disabled, and that's not a situation I want to be in. Actually, even if IPv6 was working, and IPv4 wasn't (so, a role reversal), I wouldn't want this to happen.
I certainly don't want my internet connectivity to go down while I am trying to set up IPv6 connectivity, either. I want to be able to do this transparently to the devices on the network.
Putting IPv6 and IPv4 from the same NIC into different interfaces and firewall zones is even worse, and breaks both connections, somehow.
This kind of request is best to address to the BusyBox/musl developers.
Did you observed this behavior only on operwrt with BusyBox and musl or also on a "standard" Linux distribution like Debian?
I see the point that if a router hands out GUA via RA but for some reason did not announce also a default route, that In such a scenario for sure IPv4 should be used.
Only OpenWRT.
It is an older version, though. I'll have to upgrade and check again.
On Debian systems, /etc/gai.conf also works, and precedence is configurable, so I didn't run into the issue even once, even in the days when SixXS was still around and I had that working (and sometimes not).
just in case it is of interest to you here is a draft https://datatracker.ietf.org/doc/html/draft-buraglio-6man-rfc6724-update which would updates rfc 6724.