I have a strange issue when enabling dhcp option 108 / nat64 / etc on my
#ipv6-mostly home network. I don't quite know what to make of it.
I use the apalrd fork of tayga to do NAT64. This is working great. Of note: my nat64 translator is using the well known prefix and is configured to allow access to my internal rfc1918 network. I'm using kea-3.0 for dhcp option 108 support. As a result, no ipv4 addresses are assigned to apple/android devices and they activate their clat to use with my nat64 translator. dns64 is available as well for my
#FreeBSD jails etc (which also have no ipv4 but may need to reach github etc). This is all working fine.
EXCEPT.. I have a couple of tp-link tapo C125 cameras in homekit-secure-video mode. Mostly for pet doors etc. They don't seem to like to work in ipv6-only mode even though they did acquire an ipv6 address. These are working fine with apple home and do the motion detection / record video / etc thing. I can browse the recorded video just fine. So far so good..
However, if I try to check *live video* (vs icloud recorded), then the apple gear seems to try to talk to it via ipv4 directly - without having an ipv4 address on that vlan. When looking at a phone that is involved, I see the local clat (on 192.0.0.2) and all the ipv6 addresses. And yet, it seems to be sending direct 192.0.0.2 -> 10.0.0.41 (the camera) packets on the network. Which of course, replies and the replies go to the freebsd router which drops them because they're garbage.
Thoughts:
* I know I'm not supposed to allow a nat64 on the private well-known prefix to reach back into rfc1918 space. That's fine for carrier stuff really dumb for a home network.
* Everything in the apple universe seems perfectly happy with this arrangement and uses clat/nat64 just fine.. EXCEPT live video on those couple of cameras. Is this just apple being weird?
* Kea is giving a dhcp4 reply of: "dns: 10.0.0.1, subnet mask: 255.255.255.0, option 108: 1800 seconds.". This is a bit strange. It's not assigning a pool address, nor a fixed reservation.. so why the subnet mask?
* I am wondering if perhaps the apple stuff has some workaround kludges for the nat64 spec's handing of well-known-prefix vs rfc1918 space? Maybe it is doing something like sniffing mdns or dhcp replies for other devices and using that to infer what the local network is?
* Older versions of Kea don't do dhcp option 108 properly - they tell the client to "turn off the ipv4 stack but also use this ipv4 address". Maybe apple inadvertently rely on this kind of quirk? I'm wondering if homekit secure video might have used the ipv4 address that older kea would have assigned anyway. I'll check that out in a while.
Does anyone recognize this? I'm going to tinker with the stuff I mentioned above. I figure its a long shot but maybe somebody might have an "AHA! that's easy, just do X, Y and Z!"