For IPv6, a shared listener/responder socket is not really possible
when sending to link-local IPv6 multicast addresses (ff02::/16):
The kernel needs to know which interface to use for routing.

On IPv4, this is historically a bit different, the kernel just uses
what it deems the primary/best route interface based on the routing
table. But for IPv6, a message is rejected by Linux with OSError no 99
"Cannot assign requested address" and OSError no 65 "No route to host"
on macOS.

This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4
dual-stack configurations.

As a further cleanup, move the socket options for sending multicast
packets out of the common socket creation code. For listen only sockets
those settings are not needed.

Since we allow shared lister/responder sockets, with IPv4 only sockets
now, the macOS error address in #392 is not a problem anymore.
Actually, we would like to get an exception in case we get into
this combination, so remove the explicit exception handling.

For IPv6, a shared listener/responder socket is not really possible
when sending to link-local IPv6 multicast addresses (ff02::/16):
The kernel needs to know which interface to use for routing.

On IPv4, this is historically a bit different, the kernel just uses
what it deems the primary/best route interface based on the routing
table. But for IPv6, a message is rejected by Linux with OSError no 99
"Cannot assign requested address" and OSError no 65 "No route to host"
on macOS.

This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4
dual-stack configurations.

As a further cleanup, move the socket options for sending multicast
packets out of the common socket creation code. For listen only sockets
those settings are not needed.

Since we allow shared listener/responder sockets, with IPv4 only
sockets now, the macOS error address in #392 is not a problem anymore.
Actually, we would like to get an exception in case we get into
this combination, so remove the explicit exception handling.

For IPv6, a shared listener/responder socket is not really possible
when sending to link-local IPv6 multicast addresses (ff02::/16):
The kernel needs to know which interface to use for routing.

On IPv4, this is historically a bit different, the kernel just uses
what it deems the primary/best route interface based on the routing
table. But for IPv6, a message is rejected by Linux with OSError no 99
"Cannot assign requested address" and OSError no 65 "No route to host"
on macOS.

This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4
dual-stack configurations.

As a further cleanup, move the socket options for sending multicast
packets out of the common socket creation code. For listen only sockets
those settings are not needed.

Since we allow shared listener/responder sockets, with IPv4 only
sockets now, the macOS error address in #392 is not a problem anymore.
Actually, we would like to get an exception in case we get into
this combination, so remove the explicit exception handling.

For IPv6, a shared listener/responder socket is not really possible
when sending to link-local IPv6 multicast addresses (ff02::/16):
The kernel needs to know which interface to use for routing.

On IPv4, this is historically a bit different, the kernel just uses
what it deems the primary/best route interface based on the routing
table. But for IPv6, a message is rejected by Linux with OSError no 99
"Cannot assign requested address" and OSError no 65 "No route to host"
on macOS.

This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4
dual-stack configurations.

As a further cleanup, move the socket options for sending multicast
packets out of the common socket creation code. For listen only sockets
those settings are not needed.

Since we allow shared listener/responder sockets, with IPv4 only
sockets now, the macOS error address in #392 is not a problem anymore.
Actually, we would like to get an exception in case we get into
this combination, so remove the explicit exception handling.

For IPv6, a shared listener/responder socket is not really possible
when sending to link-local IPv6 multicast addresses (ff02::/16):
The kernel needs to know which interface to use for routing.

On IPv4, this is historically a bit different, the kernel just uses
what it deems the primary/best route interface based on the routing
table. But for IPv6, a message is rejected by Linux with OSError no 99
"Cannot assign requested address" and OSError no 65 "No route to host"
on macOS.

This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4
dual-stack configurations.

As a further cleanup, move the socket options for sending multicast
packets out of the common socket creation code. For listen only sockets
those settings are not needed.

Since we allow shared listener/responder sockets, with IPv4 only
sockets now, the macOS error address in #392 is not a problem anymore.
Actually, we would like to get an exception in case we get into
this combination, so remove the explicit exception handling.

For IPv6, a shared listener/responder socket is not really possible
when sending to link-local IPv6 multicast addresses (ff02::/16):
The kernel needs to know which interface to use for routing.

On IPv4, this is historically a bit different, the kernel just uses
what it deems the primary/best route interface based on the routing
table. But for IPv6, a message is rejected by Linux with OSError no 99
"Cannot assign requested address" and OSError no 65 "No route to host"
on macOS.

This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4
dual-stack configurations.

As a further cleanup, move the socket options for sending multicast
packets out of the common socket creation code. For listen only sockets
those settings are not needed.

Since we allow shared listener/responder sockets, with IPv4 only
sockets now, the macOS error address in #392 is not a problem anymore.
Actually, we would like to get an exception in case we get into
this combination, so remove the explicit exception handling.

For IPv6, a shared listener/responder socket is not really possible
when sending to link-local IPv6 multicast addresses (ff02::/16):
The kernel needs to know which interface to use for routing.

On IPv4, this is historically a bit different, the kernel just uses
what it deems the primary/best route interface based on the routing
table. But for IPv6, a message is rejected by Linux with OSError no 99
"Cannot assign requested address" and OSError no 65 "No route to host"
on macOS.

This change rejects InterfaceChoice.Default IPv6 only or IPv6/IPv4
dual-stack configurations.

As a further cleanup, move the socket options for sending multicast
packets out of the common socket creation code. For listen only sockets
those settings are not needed.

Since we allow shared listener/responder sockets, with IPv4 only
sockets now, the macOS error address in #392 is not a problem anymore.
Actually, we would like to get an exception in case we get into
this combination, so remove the explicit exception handling.

For IPv6, a shared listener/responder socket is not really possible
when sending to link-local IPv6 multicast addresses (ff02::/16):
The kernel needs to know which interface to use for routing.

On IPv4, this is historically a bit different, the kernel just uses
what it deems the primary/best route interface based on the routing
table. But for IPv6, a message is rejected by Linux with OSError no 99
"Cannot assign requested address" and OSError no 65 "No route to host"
on macOS.

Removing the InterfaceChoice.Default config when IPv6 is enabled would
be a major breaking change. Instead, inform the user with an error log
message and a DeprecationWarning that this is not a working
configuration.

As a further cleanup, move the socket options for sending multicast
packets out of the common socket creation code. For listen only sockets
those settings are not needed.

Also don't use a shared listener/responder sockets for dual-stack mode.
Using a shared socket for IPv4 and IPv6 is especially problematic on
macOS, where the kernel does not support this and even rejects socket
options for IPv4 multicast in this case.

With a separate IPv4 socket, this actually fixes the IPv4 multicast
query sending when using the default interface. The sending will only
fail on the IPv6 socket, so IPv4 requests will make it through.

With that, the macOS error addressed in #392 is not a problem anymore.
Actually, we would like to get an exception in case we get into
this combination, so remove the explicit exception handling.

For IPv6, a shared listener/responder socket is not really possible
when sending to link-local IPv6 multicast addresses (ff02::/16):
The kernel needs to know which interface to use for routing.

On IPv4, this is historically a bit different, the kernel just uses
what it deems the primary/best route interface based on the routing
table. But for IPv6, a message is rejected by Linux with OSError no 99
"Cannot assign requested address" and OSError no 65 "No route to host"
on macOS.

Removing the InterfaceChoice.Default config when IPv6 is enabled would
be a major breaking change. Instead, inform the user with an error log
message and a DeprecationWarning that this is not a working
configuration.

As a further cleanup, move the socket options for sending multicast
packets out of the common socket creation code. For listen only sockets
those settings are not needed.

Also don't use a shared listener/responder sockets for dual-stack mode.
Using a shared socket for IPv4 and IPv6 is especially problematic on
macOS, where the kernel does not support this and even rejects socket
options for IPv4 multicast in this case.

With a separate IPv4 socket, this actually fixes the IPv4 multicast
query sending when using the default interface. The sending will only
fail on the IPv6 socket, so IPv4 requests will make it through.

With that, the macOS error addressed in #392 is not a problem anymore.
Actually, we would like to get an exception in case we get into
this combination, so remove the explicit exception handling.

For IPv6, a shared listener/responder socket is not really possible
when sending to link-local IPv6 multicast addresses (ff02::/16):
The kernel needs to know which interface to use for routing.

On IPv4, this is historically a bit different, the kernel just uses
what it deems the primary/best route interface based on the routing
table. But for IPv6, a message is rejected by Linux with OSError no 99
"Cannot assign requested address" and OSError no 65 "No route to host"
on macOS.

Removing the InterfaceChoice.Default config when IPv6 is enabled would
be a major breaking change. Instead, inform the user with an error log
message and a DeprecationWarning that this is not a working
configuration.

As a further cleanup, move the socket options for sending multicast
packets out of the common socket creation code. For listen only sockets
those settings are not needed.

Also don't use a shared listener/responder sockets for dual-stack mode.
Using a shared socket for IPv4 and IPv6 is especially problematic on
macOS, where the kernel does not support this and even rejects socket
options for IPv4 multicast in this case.

With a separate IPv4 socket, this actually fixes the IPv4 multicast
query sending when using the default interface. The sending will only
fail on the IPv6 socket, so IPv4 requests will make it through.

With that, the macOS error addressed in #392 is not a problem anymore.
Actually, we would like to get an exception in case we get into
this combination, so remove the explicit exception handling.

For IPv6, a shared listener/responder socket is not really possible
when sending to link-local IPv6 multicast addresses (ff02::/16):
The kernel needs to know which interface to use for routing.

On IPv4, this is historically a bit different, the kernel just uses
what it deems the primary/best route interface based on the routing
table. But for IPv6, a message is rejected by Linux with OSError no 99
"Cannot assign requested address" and OSError no 65 "No route to host"
on macOS.

Removing the InterfaceChoice.Default config when IPv6 is enabled would
be a major breaking change. Instead, inform the user with an error log
message and a DeprecationWarning that this is not a working
configuration.

As a further cleanup, move the socket options for sending multicast
packets out of the common socket creation code. For listen only sockets
those settings are not needed.

Also don't use a shared listener/responder sockets for dual-stack mode.
Using a shared socket for IPv4 and IPv6 is especially problematic on
macOS, where the kernel does not support this and even rejects socket
options for IPv4 multicast in this case.

With a separate IPv4 socket, this actually fixes the IPv4 multicast
query sending when using the default interface. The sending will only
fail on the IPv6 socket, so IPv4 requests will make it through.

With that, the macOS error addressed in #392 is not a problem anymore.
Actually, we would like to get an exception in case we get into
this combination, so remove the explicit exception handling.