Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Service announcements are not sent over IPv6 #10

Open
A1bi opened this issue Feb 21, 2021 · 3 comments
Open

Service announcements are not sent over IPv6 #10

A1bi opened this issue Feb 21, 2021 · 3 comments
Labels
enhancement New feature or request long running Issues which should be excluded from the stale bot

Comments

@A1bi
Copy link

A1bi commented Feb 21, 2021

Describe the Bug

I am running some devices with IPv4 disabled to test out an IPv6-only environment. This shouldn't be a problem for Bonjour services as they are expected to utilize both IPv4 and IPv6 and therefore make their service announcements or responses using both protocols. This is also the behavior recommended in RFC 6762:

A dual-stack (v4/v6) host can participate in both ".local." zones, and should register its name(s) and perform its lookups both using IPv4 and IPv6. This enables it to reach, and be reached by, both IPv4-only and IPv6-only hosts.

I noticed that my custom HomeKit devices (using HAP-NodeJS with the ciao backend) are not reachable from an IPv6-only client. Turns out that the mDNS announcements and respones are sent only using the IPv4 multicast address. The client (a Mac) therefore can't discover the HomeKit devices and as a result shows them as unresponsive. This is not the case with the official Bonjour implementation. I have no issues discovering my Apple TV or any other Apple device on my network, because they are sending out announcements using both protocols (verified with Wireshark).

I looked at the code and noticed that IPv6 is taken into consideration in a lot of places, but ultimately IPv4 is hardcoded here when sending out anything on the network and in some other places. Same hardcoding applies to binding the listening socket, although netstat shows that ciao is indeed listening to IPv6. I guess the operating system automatically opens a dual stack socket if :: is provided as the listening address?

To reproduce

Disable IPv4 on a client and try to discover a service announced with ciao.

Expected behavior

Services announced using ciao should be discoverable on IPv6-only hosts.

Environment

  • Node.js Version: 14.15.5
  • Yarn Version: 1.22.5
  • Operating System: Raspbian
@A1bi A1bi added the bug Something isn't working label Feb 21, 2021
@Supereg
Copy link
Member

Supereg commented Feb 21, 2021

You are correct. ciao doesn't yet listen on the IPv6 multicast address as defined in the RFC and thus will not work in ipv6 only environments.
This enhancement is on our list, but hasn't been worked on.

@Supereg Supereg added enhancement New feature or request long running Issues which should be excluded from the stale bot and removed bug Something isn't working labels Feb 21, 2021
@adriancable
Copy link
Contributor

@A1bi / @Supereg - my PR #19 tries to do this.

@A1bi
Copy link
Author

A1bi commented Mar 7, 2022

@adriancable Awesome, great work!

I also want to point out that you can now alternatively use the new avahi advertiser with HAP-NodeJS (and therefore with Homebridge as well) which provides a complete IPv6 implementation. Works flawlessly with my IPv6-only setup. Credits for this addition again go to @adriancable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request long running Issues which should be excluded from the stale bot
Projects
None yet
Development

No branches or pull requests

3 participants