Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think one of the reasons it is hard to use, is that support is almost, but not quite there.

What I did not have time to write-up is the bootload of vendor-specific bugs, that are also firmware version dependent. Those are often easy-enough to work around once you know them, but very hard to figure out what is going on.

I've encountered: - AppleTV creating incorrect TCP checksums for packets of youtube/netflix apps, when using 464xlat with a custom prefix. Happens on cable, does not happen on wifi. - MikroTik not sending out RAs with 0 lifetime. - Android VoIP not accepting fragmented IPv6 packets when using 464xlat. - LG WebOS TV supporting dhcp option 108 over cable, not supporting over wifi. - Unifi Multicast enhancements filtering out solicited IPv6 RA-s, but letting through unsolicited RA-s.

And there are also vendor specific non-bugs, like to enable xlat, Android wants ipv6-mapped ipv4 on the domain ipv4only.arpa, whereas iOS wants the prefix in the RA.

And don't even get me started on random Matter devices which think that it's fine for them to just start advertising an ipv6 prefix without any configurability.



Just today I had another fun one. I spun up a Debian VM and of course IPv6 was turned on by default. Well, this site didn't have IPv6 so it just got a link local address.

Well, turns out Debian's apt servers are hosted by Fastly and they have AAAA records, which apt of course tried to use because well, the host technically had a valid IPv6 address I suppose.

So had to disable IPv6 before I could get apt update to work again, yay...




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: