> IPV6_V6ONLY and net.inet6.ip6.v6only have no effect in OpenBSD. The > setsockopt does fail if you try to set it to a different value than the > sysctl. So there is no additional risk here because OpenBSD denied early > on the double usage of IPv6 sockets for IPv4 connections.
Correct. If tomorrow we allowed the knob... what % of pf.conf out there are ready for it? Going further: If we adjusted the auto-tunnel code to work, and tomorrow we shipped a snapshot with net.inet6.ip6.v6only=0, what percentage of people would be unharmed? I believe everyone with v6 feed would be harmed. It isn't just about pf.conf rules. Our stateful packet filter finds itself incapable of handling this perfectly. Stateful handling is unaware. Automatic tunnels at L2L3 edge are a terrible idea, because inet4 and inet6 have very subtle semantic differences, and an attacker capable of providing v4 traffic via both paths would exercise those edge conditions to bypass controls. Sometimes people put a bad idea into an RFC. Later they discover it is impossible to walk the idea back to the garbagebin. The result is concepts so complicated that everyone has to be a fulltime expert, on admin side and coder side. > But I doubt this justifies that we add the compat goo (which is > missing from all the other daemons as well). Correct, the knob handling missing from all the non-portable codebases. Some -portable's add it back, some don't. In general, I think -portable's should not add it back without really clear justification. The automatic tunnels are just as risky outside OpenBSD, because their packet filter tools encounter the same difficulty protecting against abuse. Inside our ports tree, how much software is aware of this? Very little. So why should our -portable code be aware of it, when so many people on our side reject the concept?
