IPv6 is absent from the kernel on every board, inherited from stock rather than decided: what enabling it would take

[mcfbytes]

The image has no IPv6 at all — not disabled in userspace, absent from the kernel. That is
worth an explicit decision rather than continued inheritance, because the reason it is off
turns out to be "stock had it off" and nothing more.

Current state

board/mister/de10nano/linux.config:106        # CONFIG_IPV6 is not set   (DE10, and RT — see below)
board/mister/common/linux-mister.fragment:195 # CONFIG_IPV6 is not set   (DE25)
work/stock-linux.config                       # CONFIG_IPV6 is not set   (stock)
output-rt/build/linux-7.2.4/.config           # CONFIG_IPV6 is not set   (RT, resolved)

The DE25 fragment states the rationale in full: "IPv6 is OFF, matching the DE10 and
stock." And the DE10's line carries no comment at all. So the chain is parity-with-stock
inherited twice, not a decision anybody made on the merits. CONFIG_IPV6 is
tristate … default y in net/ipv6/Kconfig, so both we and stock are actively turning it
off.

Consequence: no link-local addresses, no SLAAC, no DHCPv6, no ::1. Every daemon is v4-only
— not because it is configured that way, but because the kernel offers nothing else.

Only two files need the kernel change, because package/linux-rt/linux-rt.mk:59 reuses
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE, so the DE10's config covers the RT build too.

Already IPv6-ready — this is less work than it looks

• busybox: CONFIG_FEATURE_IPV6=y in the resolved config, so the applets are v6-capable.
• dhcpcd: etc/dhcpcd.conf:48 already carries slaac private. The SLAAC configuration
  is sitting there waiting for a kernel that can use it.
• sshd: etc/ssh/sshd_config:14-16 leaves AddressFamily, ListenAddress 0.0.0.0 and
  ListenAddress :: all commented out, i.e. defaults, i.e. both families.
• ip6tables is already built and installed — output/target/sbin/ip6tables,
  -restore, -save, -apply, plus the -legacy variants. The userland firewall tooling
  exists; only the kernel tables are missing.
• Python, OpenSSL, libcurl, Samba and ntpd are all v6-capable as built.

What would have to change

Kernel

• CONFIG_IPV6=y in board/mister/de10nano/linux.config and
  board/mister/common/linux-mister.fragment. =y, not =m — net/ipv6/Kconfig:6
  warns "IPv6 as module will cause a CRASH if you try to unload it".
• Netfilter v6 mirroring the legacy v4 set already present (CONFIG_IP_NF_IPTABLES=y,
  CONFIG_IP_NF_FILTER=y, CONFIG_NETFILTER_XTABLES_LEGACY=y):
  CONFIG_IP6_NF_IPTABLES, CONFIG_IP6_NF_IPTABLES_LEGACY, CONFIG_IP6_NF_FILTER,
  CONFIG_IP6_NF_TARGET_REJECT, CONFIG_NF_LOG_IPV6. Conntrack is already y and is
  family-agnostic.
• A pre-existing gap this would inherit: the RT kernel has CONFIG_NETFILTER=y,
  CONFIG_NETFILTER_XTABLES=y and CONFIG_IP_NF_IPTABLES=y but no CONFIG_IP_NF_FILTER
  in its resolved config at all — there is no v4 filter table on RT today, so iptables
  loads and has nowhere to put a rule. Adding IPv6 on top of that makes an existing hole
  wider. This needs fixing first or alongside.
• Size cost is unmeasured. A make linux-rebuild before and after would settle it. It
  matters more here than usual: linux.img ships gzipped and the sdcard installer runs
  under a mem=511M cap.

Userland

• etc/hosts currently holds only 127.0.0.1 localhost and 127.0.1.1 MiSTer. Needs
  ::1 localhost ip6-localhost ip6-loopback and the conventional ff02::1 / ff02::2
  entries.
• etc/proftpd.conf:14 is an explicit UseIPv6 off. Flipping it is one line; whether we
  should is the security question below.
• busybox: CONFIG_FEATURE_IFUPDOWN_IPV6 is off, so iface … inet6 stanzas in
  /etc/network/interfaces would be silently misparsed if anyone adds one.
  CONFIG_PING6 and CONFIG_TRACEROUTE6 are also off — ping -6 works via
  FEATURE_IPV6, but there is no ping6/traceroute6 binary, which is what most
  troubleshooting instructions on the forum will tell a user to run.
• /etc/network/interfaces: the wlan stanzas are inet manual with dhcpcd doing the
  addressing, so they may need no change at all — worth verifying rather than assuming,
  given the guard/poll logic already living in those stanzas.
• sysctl policy to decide and document: accept_ra, use_tempaddr (privacy addressing),
  and a supported disable_ipv6 opt-out for users who want it off.

Security — this is the gate, not a footnote

Today the board is shielded from the internet substantially by accident: IPv4 NAT.
SLAAC hands out a globally routable address the moment any router on the segment advertises
a prefix. ADR 0031 already records what is listening behind that accident — root:1 over both
SSH and FTP, anonymous writable FTP, Samba, and SECCOMP off. Turning IPv6 on without a
firewall converts "unreachable because NAT" into "reachable from the internet", and users
will not know it happened.

So enabling IPv6 requires one of:

1. a default-deny ip6tables INPUT ruleset plus an init script to load it (and the RT
   filter-table fix above, or it is unenforceable on the RT kernel); or
2. IPv6 compiled in but administratively off (net.ipv6.conf.all.disable_ipv6=1) with a
   documented opt-in, which gets us the capability without changing anyone's exposure.

Either way this belongs in ADR 0031 before it ships. Option 2 is the cheap, honest first
step; option 1 is the real feature.

Things that degrade, that we do not control

• The OSD stops showing an address on a v6-only network. Main_MiSTer/menu.cpp:680-681
  filters on ifa->ifa_addr->sa_family == AF_INET for both eth0 and wlan*, so an
  interface holding only IPv6 addresses displays nothing. Upstream's code — per our policy
  that is a report to hand over, not a drive-by PR. Dual-stack hides it entirely, which is
  another argument for dual-stack over v6-only.
• mister.lan discovery. We ship no mDNS responder, so the name works because the
  router registers the DHCPv4 hostname. Dual-stack keeps that; v6-only would lose it.

Docs and CI

• scripts/ci-tests.sh contains no IPv6 assertions of any kind.
• docs/wifi-parity.md, docs/ssh-ftp-parity.md, docs/netfs-parity.md and
  docs/kernel-config-deltas.md all describe a v4-only world and would need updating.
• No ADR or doc anywhere currently explains why IPv6 is off — this issue is the first
  place that question has been written down.

Recommendation

Dual-stack, never v6-only — it keeps mister.lan, keeps the OSD address display
working, and makes the whole change additive.

Land it in two steps. First the kernel symbols plus /etc/hosts, the busybox applets
and the ip6tables tables, shipped with disable_ipv6=1 by default: that makes the image
capable without changing anyone's exposure, and it is reviewable on its own. Then the
firewall ruleset and the default flip as a second change, dispositioned in ADR 0031.

Two questions for @mcfbytes before any of this starts:

1. Is diverging from stock acceptable here? Stock is v4-only, and this project's default
   posture is parity. An IPv6-capable image is a deliberate divergence — a defensible one,
   since IPv6-only and v6-preferred home networks are no longer exotic, but it should be a
   stated choice rather than a side effect.
2. On by default, or opt-in? This is really "do we ship a firewall", and it is the same
   question ADR 0031 is already holding open for IPv4.

Work items

• Decide the two questions above; record the outcome in ADR 0031.
• Measure the linux.img size delta from CONFIG_IPV6=y on all three kernels
  (DE10, RT, DE25).
• Fix the missing CONFIG_IP_NF_FILTER on the RT kernel — pre-existing, independent of
  this issue, and blocking any firewall story.
• Kernel symbols in the two config files; verify all three resolved .configs.
• /etc/hosts, busybox PING6/TRACEROUTE6/FEATURE_IFUPDOWN_IPV6, proftpd
  UseIPv6, sysctl policy.
• ip6tables default ruleset + init script, if question 2 says "on by default".
• CI assertions; rig test on both Ethernet and WiFi, dual-stack and v4-only.
• Report the AF_INET filter in menu.cpp upstream (needs @mcfbytes' go-ahead).
• Update the four docs listed above.