IPV6 not failing back to IPV4

[MattWestb]

If having local IPV6 but not IPV6 from ISP and the ISP DNS is doing IPV6 lockups OK is this module not working then its not testing IPV4 that working and getting error in the log.

Logger: homeassistant.components.analytics
Source: components/analytics/analytics.py:289
Integration: Analytics (documentation, issues)
First occurred: January 27, 2023 at 08:55:21 (2 occurrences)
Last logged: 08:55:21

Timeout sending analytics to https://analytics-api.home-assistant.io/v1

And ping from inside the container.

PING analytics-api.home-assistant.io (2606:4700:20::ac43:445a): 56 data bytes
^C
--- analytics-api.home-assistant.io ping statistics ---
19 packets transmitted, 0 packets received, 100% packet loss

I know its one not working ISP setting but i cant changing it the the ISP dont accepting it and its right they saying (instead delivering true IPV6).

But i think the module shall falling back to IPV4 if 6 is not working.

[ludeeus]

You should disable v6 on your host if you can not use it.
This is not something this service can do anything about.

[MattWestb]

Great help and how is my Silabs Multi protocol with thread and 3 boarder router working then then can only talking IPV6 ???

https://github.com/home-assistant/addons/tree/master/silabs-multiprotocol

[Jc2k]

AIUI it's normal for asyncio to use happy eyeballs to handle cases like this isn't it?

python/cpython#7237

Unfortunately aiohttp doesn't support it yet: aio-libs/aiohttp#4451

[agners]

By default, DNS looks up IPv6 as well. However, the local socket connection should choose (and/or revert to) IPv4 if IPv6 connectivity is unavailable. For some reason ping/aiohttp descides that IPv6 is available.

What type of local IPv6 deployment do you have? ULA address space?

[MattWestb]

I have one Netgear R6400 v2 with DD-WRT Prefix Length 64 and using the standard IPV6 Radvd for DNS service. and Radvd custom config:

interface br0 {
   AdvSendAdvert on;
   prefix 0:0:0:1::/64 {
    AdvOnLink on;
    AdvAutonomous on;
   };
};

for getting the WiFi being bridged to the LAN.

By the way is the Supervisor installer having the same problem if trying (re)running it it cant ping the IPV6 and and is not going thru the install.
All other HA integrations and addons looks working OK and all device in my LAN is not having any problems (but is still bad done from UPC / Magenta).

[agners]

Hm, 0:0:0:1::/64 does not seem to be an ULA address, but typically used for IPv6 to IPv4 bridges (at least judging from this DD-WRT article). I assume that your Home Assistant host (and probably any other host in your network) now assume that there is full IPv6 connectivity (through the IPv6 to IPv4 bridge) and hence try to access the host using IPv6. IPv6 is typically preferred over IPv4, if the dual-stack host has a valid IPv6 address. Can you try pinging analytics-api.home-assistant.io from another host on your network? Also a good test is ipv6-test.com.

That local IPs resolve, and other remote systems work is probably because those local devices or remote system have only IPv4.

I think RFC 6724 is the address selection process which should be adhered by any dual-stack host.

[MattWestb]

Windows 10 is pinging IPV4 OK All Linux also Ubuntu AMD64 is trying IPV6 without susses have, have not trying Android.
ipv6-test.com is saying no IPV6 DNS only IPV4.

I think the problem is 0:0:0:1::/64 then UPC is not supporting IPV6 or 6to4.
Is it one better ULA address to using so native IPV6 is working local LAN and not trying 6to4 for all Linux machines ?
I like using IPV6 so my OTFD-CLI can communicating over IPV6 with all other machines in the network (also WiFi) thru the OTBRs.

The strange things where is Radvd DNS service getting there IPV6 DNS information that shall not being possible and is making its braking.

[agners]

I think the problem is 0:0:0:1::/64 then UPC is not supporting IPV6 or 6to4.

From what I understand, your manual Radvd configuration basically tells your network that there is global IPv6 connectivity by using prefix 0:0:0:1::/64, and I assume that your router is set as default route for all IPv6 traffic. However, it seems that your router is not actually able to route IPv6 traffic, so connection fail. In the end this is a router miss-configuration.

Is it one better ULA address to using so native IPV6 is working local LAN and not trying 6to4 for all Linux machines ?

The official ULA range is fd00::/8. I am not familiar with DD-WRT, but in OpenWrt generates a ULA prefix automatically (you can see it at Network -> Interfaces -> Global network options). Also when a ULA prefix is used, clients don't configure the router as default route for IPv6 traffic. Therefor, clients know that they should not use IPv6 addresses to connect externally.

In my testing, a network with only ULA IPv6 address range configured, does not push a default route to clients (ip -6 route does not show a default route for IPv6 traffic), and HA selects IPv4 as expected:

bash-5.1# ping analytics-api.home-assistant.io
PING analytics-api.home-assistant.io (172.67.68.90): 56 data bytes
64 bytes from 172.67.68.90: seq=0 ttl=49 time=7.769 ms

However, you don't need to configure anything IPv6 on your router to make Matter/Thread/OTBR work! Matter uses mDNS/DNS-SD on the network which works with IPv6 link local addresses (those automatically assigned IPv6 addresses with prefix fe80::/10). Matter for WiFi/Ethernet devices works just fine on a local network without any global or ULA prefix. FWIW, it only really works on a local network, as it uses DNS-SD and mDNS, the latter uses local-local multicast address ff02::fb.

A Thread border router generates a on-mesh routeable prefix (a ULA prefix which is used on the Thread network) and announces a route for that network on the main/Ethernet network via ICMPv6 route information. Also this mechanism does not need more than a link-local address: IPv6 routes work perfectly fine with fe80::/10 addresses.

So, best chance to make things work properly is to not configure anything on your router 😄

[MattWestb]

Thanks Stefan !!
I was changing Radvd custom config to:

interface br0 {
   AdvSendAdvert on;
   prefix fe80::/10 {
    AdvOnLink on;
    AdvAutonomous on;
   };
};

and now all IPV6 machines looks working OK and getting one link local address and one prefix fe80: also all docker interface on them like Armbian arm32 Ubuntu Eth:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.64  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::9997:fc1f:e615:1a85  prefixlen 64  scopeid 0x20<link>
        inet6 fdff:1111:1122:22ee:d98b:dda4:d1e6:928e  prefixlen 64  scopeid 0x0<global>
        ether 3e:81:7f:c0:ba:b0  txqueuelen 1000  (Ethernet)
        RX packets 1937697  bytes 617515986 (617.5 MB)
        RX errors 1  dropped 0  overruns 0  frame 0
        TX packets 960005  bytes 386796200 (386.7 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 47

Only thing is that my Thread android app cant connecting to the 3 OTBR for commissioning but i think i need re commissioning it then the token is not valid then the network is changed (or is Matter server / client changing the commissioner setting in them).

Thanks for help and fixing the problem and i think its good to have fixing it for other user that getting the same problems in the near future (with OTBR and Matter coming online).

[agners]

Thanks Stefan !! I was changing Radvd custom config to:

interface br0 {
   AdvSendAdvert on;
   prefix fe80::/10 {
    AdvOnLink on;
    AdvAutonomous on;
   };
};

Note that for link-local address configurations (fe80::/10) you don't need Radvd! These type of addresses are automaticallyi assigned by any IPv6 interface.

Is radvd really accepting fe80::/10 as prefix (no error in the logs)?