Listening on IPv4 and IPv6 addresses

[galexrt]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

We have UDP based services that are able to run on IPv4 and IPv6 this helps users that have a "weak" IPv4 connectivity due to, e.g., their ISP providers lacking the IPv4 bandwidth (packet loss at the ISP's backbones as far as we have analyzed in most situations that we encountered).
For that we would like to run service accessible over IPv4 and IPv6.

Describe the solution you'd like

It would be great if quilkin had an option to listen on IPv4 and IPv6 addresses so users with a better IPv6 connectivity due to, e.g., ISP "uplink" limitations. Especially as quilkin seems to be capable to sending IPv4 traffic to IPv4 and IPv6 endpoints already from what I have read in the documentation and examples.

Describe alternatives you've considered

We can go IPv4-only but in the past even that has shown to cause some issues for "less optimized" services for users with ISPs that

[XAMPPRocky]

Thank you for your issue! This is something I definitely think we should add, and I’ve already been working on improving the code around here to make it easy to have multiple listeners in the the same process, and working on improving Quilkin’s Quality Of Service story and this feature definitely fits in that bill.

To me, the only thing to figure out is how to integrate it into Quilkin in a way that’s consistent with other features such as xds, and that makes it a compelling part of project. Here are some open questions I have of how it can integrate in Quilkin.

• Is possible for this to be on by default and possibly not an option? While IPv6 still struggles to gain adoption in terms of network traffic, how reasonable is it for us to assume IPv6 support on machines that run Quilkin?
• If in the future we allowed users to listen on multiple ports, with this “IP mirroring” feature. Would the feature be feature be “all port listeners are mirrored”, or would there be a motivating reason for having it be configured per listener?

[markmandel]

Now that #752 is merged, @XAMPPRocky can you see any reason to not use the DualStackLocalSocket everywhere in Quilkin, and close this out?

quilkin/src/utils/net.rs

Lines 55 to 58 in 57244b4

	pub struct DualStackLocalSocket {
	v4: UdpSocket,
	v6: UdpSocket,
	}

[XAMPPRocky]

Nope, we should replace existing uses with this

[markmandel]

Sounds good - I'll get on it.

[markmandel]

Just dropping a note to update - this will be my task for the next 0.7.0 release 👍🏻

[markmandel]

Started work on this, so breaking things and trying to make it all work again 😄

[markmandel]

Final working piece is to work out the firewall rule:

The idea we had was to have multiple sources in the config:

version: v1alpha1
filters:
  - name: quilkin.filters.firewall.v1alpha1.Firewall
    config:
      on_read:
        - action: ALLOW
          sources: 
            - 192.168.51.0/24
            - ::1/128
          ports:
             - 10
             - 1000-7000

Then it also means that this reduces some boilerplate overall.