Orders ipv6 addresses before v4 in resolution (needs a happy eyeballs implementation that supports feeding in resolved addresses)

[tlm]

When performing mdns or dns resolution for a given hostname v4
addresses are always returned for the connection over v6 when an address
supports dual stacks.

This allows for ipv6 transitioning and testing in a dual stack
environment. It also follows common practice when picking the right
address to try first.

Not addressed by this commit is the ability to fall back to other
resolved addresses should the first address fail. This feature is
addressed by other todo's in the project.

[bdraco]

Here is the logic we use in Home Assistant Core to get the preferred ip.

We tried to return IPv6 first but it caused too many problems for users

    for address in addresses:
        ip_addr = ip_address(address)
        if (
            not ip_addr.is_link_local
            and not ip_addr.is_unspecified
            and ip_addr.version == 4
        ):
            return str(ip_addr)
    # If we didn't find a good IPv4 address, check for IPv6 addresses.
    for address in addresses:
        ip_addr = ip_address(address)
        if (
            not ip_addr.is_link_local
            and not ip_addr.is_unspecified
            and ip_addr.version == 6
        ):
            return str(ip_addr)
    return None

[bdraco]

Here is the logic we use in Home Assistant Core to get the preferred ip.

We tried to return IPv6 first but it caused too many problems for users

    for address in addresses:
        ip_addr = ip_address(address)
        if (
            not ip_addr.is_link_local
            and not ip_addr.is_unspecified
            and ip_addr.version == 4
        ):
            return str(ip_addr)
    # If we didn't find a good IPv4 address, check for IPv6 addresses.
    for address in addresses:
        ip_addr = ip_address(address)
        if (
            not ip_addr.is_link_local
            and not ip_addr.is_unspecified
            and ip_addr.version == 6
        ):
            return str(ip_addr)
    return None

[tlm]

Thanks @bdraco for the information. Are you able to provide a link to the code in ha core?

Are you able to elaborate on the problems faced when preferring v6 over v4 first in a dual stack environment? This method is considered the best practice in RFC's.

I know from my own personal env I would prefer it if HA would be more v6 first. Makes it very hard to go completely single stack for IOT devices.

[bdraco]

Thanks @bdraco for the information. Are you able to provide a link to the code in ha core?
https://github.com/home-assistant/core/blob/dev/homeassistant/components/zeroconf/__init__.py#L557

Are you able to elaborate on the problems faced when preferring v6 over v4 first in a dual stack environment? This method is considered the best practice in RFC's.

Lots of users have broken IPv6. The issue queue in HA is full of them.

I know from my own personal env I would prefer it if HA would be more v6 first. Makes it very hard to go completely single stack for IOT devices.

If we were to do IPv6 we would need to implement happy eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs

[bdraco]

zeroconf now has a guarantee on ip address order return that matches the above pattern.

https://github.com/python-zeroconf/python-zeroconf/blob/d713a458daf6a57eea934b384cc9e534b33fd334/src/zeroconf/_services/info.py#L244

This should make it a lot simpler.

https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.create_connection

We can drop _connect_socket_connect and let asyncio make the connection in _connect_init_frame_helper with happy_eyeballs_delay of 0.25

[bdraco]

@tlm Is this something you are still interested in pursuing?

[tlm]

@bdraco It is, but not something I have the time to finish up at the moment. Happy to close and I can breathe some more life into this another day.

[bdraco]

We effectively have same problem as aio-libs/aiohttp#4451 (comment)

[bdraco]

@tlm Any interest in testing #789

[tlm]

Would love to @bdraco

[bdraco]

#789 is available in 20.0.0