Hello. I want to build an IPv4-only image and disable IPv6 in odhcpd. I did follow the instructions in https://wiki.openwrt.org/doc/techref/odhcpd on how to turn off IPv6 in odhcp. However, on boot odhcp prints error messages into syslog:
Tue Mar 20 09:34:17 2018 daemon.err odhcpd[1693]: Failed to open routing table: No such file or directory
Tue Mar 20 09:34:17 2018 daemon.err odhcpd[1693]: Unable to open raw socket: Address family not supported by protocol
What is the correct way to disable IPv6 functionality in odhcp without breaking DHCP services for IPv4? If I did understand it correctly, odhcp serves both address families, so it is still needed for IPv4, right?
Thank you, dibdot! I was not sure about possible replacement of dnsmasq IPv4 DHCP, since odhcpd remains selected in menuconfig even if IPv6 is disabled in global build settings.
If I'm not wrong, odhcpd handles obtaining IPv4 and IPv6 from WAN, and assigning IPv6 to LAN; while dnsmasq handles assigning IPv4 to LAN.
Instead of disabling / removing odhcpd, you can remove "wan6" interface, and ip6class references on lan in the /etc/config/network file. This should prevent the router from attempting to obtain IPv6 from upstream and distributing it to LAN.
That being said, Internet is slowly moving to IPv6. Hence I'm curious why is there a need to disable it?
Did so already, but still errors were being logged by odhcpd. Call me nit-picking, but I'm used to reduce packages and services to what I actually need in order to minimize inappropriate error messages in logs, which often irritate support people and end-users if something other did go wrong and needs to be tracked down.
Several reasons. The first one you named it: Internet is slowly moving to IPv6, but too slowly, see second reason. I do observe this for 20 years now and IMHO its development has been somewhat chaotic to say at least. Second: ISPs often don't offer IPv6 in business tariffs at all (e.g. Unitymedia). Migrating in the private sector is a completely different (and almost easy) task compared to migration in industrial environments, where production needs to be kept up and running all the day. Third: our application still (more precisely: again) isn't IPv6-ready. Its basic concept has been levered out when IPv6 privacy extensions have been introduced, so the application will need a complete re-design. This isn't as easy as it sounds, given a large installation base which has to be migrated.
Anyway, thanks for your suggestions; I now could build a firmware image w/o odhcpd and it's running fine.
See, 20 years is very slow given the time span the Internet did change from USEnet over dialup lines to Ethernet. I'm more concerned about the traffic in industrial local networks than traffic to Google, Facebook, Youtube etc. And wether I like it or not: our clients currently refuse to migrate their networks to IPv6, but they don't need to use Google, Facebook or Youtube anyhow.
The last 20 years is more or less irrelevant. It's the last 3 where the explosion really began. The traffic to google is indicative of the availability of ipv6 to end-users. Once more than 50% of end user traffic is capable of ipv6, the incentives to delay on the part of commercial will dissipate quite a bit. ipv6 is by far a better and easier to manage protocol. I fully expect a major dive into ipv6 by commercial providers in 2019, maybe second half or early 2020.
So I'm not saying that you shouldn't do whatever you're doing, just pushing back against the idea that ipv6 is a long way off.
No contradiction. For the end-user market you are completely right! Definitely SmartPhones and IoT did accelerate migration in last 6 years. But as for industrial networks, 2019 is way too optimistic IMHO. But we will see, maybe I'm wrong.
If by industrial you mean things like refinery control systems or the like, then that stuff will move super slow. But if by industrial you mean commercial office buildings and soforth, then I fully expect ISPs to start offering ipv6 to office buildings etc very soon.
The real question is when does the demand arrive? Once you can attract customers by being the only commercial ISP in a region to offer ipv6 you will see people competing, and rapidly ramping up ipv6. That won't happen until ipv6 is common for the end user, since commercial people are basically providers of services to end users. So if mid 2018 we see more than 50% of end users in the US have ipv6, companies will start to realize that and want to offer services that only work well on ipv6 (end-to-end). so we'll see.
Yes, I mean control systems and telecontrol systems, where hardware won't and can't be replaced every two years or so.
At my place, ISPs offering native IPv6 or DS-lite can only provide very limited bandwidth up to 16 Mbps down, 0.7 Mbps up. The only ISP here offering higher bandwidth up to 400 Mbps still uses IPv4 for commercial (business) customers, albeit private customers of the same ISP do get IPv6 already. So there is not much ISP competition at the moment for businesses and according to the ISPs I asked it won't be changed in near future. Sure, I could use a tunnel broker, but hey, I have to get my work done at the end of the day and don't have that much time for driving Google traffic to IPv6.
Agreed then, those are extremely slow to change. My impression is lots of them still run FORTH code on 8 bit microcontrollers from the late 1970's
Undoubtedly because the number of commercial customers who need ipv6 to provide services to their own customers is small. But once 50% of consumer customers have ipv6 then businesses will start offering services that only work well on ipv6... and then the ISPs will start to get daily calls saying "hey why can't I get IPV6 I want to provide stuff that requires it" and so the business case suddenly exists for commercial ISPs. Besides, they'll be debugging all their ipv6 problems on the consumer end, where they have no service level agreements. By the time they've got it all working well there, they can cut-over the commercial stuff and not break their SLA relatively easily.
So far the curve for google traffic looks like typical logistic growth. It's exponential initially, then as it hits about 50% it becomes linear, and then asymptotes to 100% in the long time limit. I'd expect a similar logistic growth, but delayed, for the commercial sector, and with a faster time-scale. The commercial sector will follow the demand from the consumers. The question is when will commercial people start providing services that really only work well on ipv6. The drivers will be things like VPN, teleconferencing, remote support services, private clouds, anything where it helps tremendously to be able to end-to-end connect two devices without all the NAT/port forwarding baloney.
The recent revelations about privacy may also drive people to want their own private clouds, so people will start offering even more of those NAS devices and consumers will start to say "Hey how come I can access this thing from my phone, but it doesn't work at the coffee shop on my laptop" and the answer will be "because your phone has ipv6 and can reach your home network, the coffee shop is still stuck on ipv4 only" Having lots of consumers who want that kind of thing will drive a lot of conversion
Anyway, good luck with your thing, if you're working on industrial systems sounds like you have legit reasons to want to eliminate ipv6. My main reason to comment here is for others who might see "hey I could eliminate ipv6 too and save some space" but may have less background knowledge about how the transition is progressing.
Nothing bad about FORTH and if you still have some 8080 CPUs with RISC architecture or SBP 9900 with I²L technology lying around somewhere (I do have one in an epoxy box, LOL): Not so long ago NASA did pay good prices on eBay for those chips, since they have been well known to be most faultlessly and super-robust for spacecraft missions.
I absolutely agree with you. I also would prefer to do remote support through a fixed IPv6 address instead of having to set up reverse ssh tunnels with kind of command & control center to initiate connections for a remote call. That would be much nicer to handle.
Definitely. See, I would be lucky to have one IP per device instead of fiddling with NAT on routers. But there is a private side and a line for work. In my spare time I enjoy Hyperborea and connecting people around me through cjdns over encrypted, IPv6-based meshed connections. On the other side there is the work for a living and the customer. He defines what I have to deliver to him in order to compete with others.
To be clear: it's neither about nostalgia nor about saving space, I have plenty of space, hard to waste with an embedded Linux. And when there is more time to clean up inherited burdens, I definitely will introduce IPv6 "under the hood" of the system. Remote support is a good argument to convince customers.
Anyway, I enjoyed this discussion with you very much. Also best wishes to you!
And when there is more time to clean up inherited burdens, I definitely will introduce IPv6 "under the hood" of the system. Remote support is a good argument to convince customers.