search

envoyproxy / envoy

Cloud-native high-performance edge/middle/service proxy
https://www.envoyproxy.io
Apache License 2.0
24.95k stars 4.8k forks source link

Smarter way to pick endpoints for dual-stack IPv4/v6 support #16123

Closed nrjpoddar closed 3 years ago

nrjpoddar commented 3 years ago

Title: Support smarter way to send traffic to IP family endpoint based on downstream connection

Description: We are working on supporting dual-stack IPv4 and IPv6 in Istio. As part of configuring Envoy via Istio control plane for dual-stack we are wondering what's the best way to avoid duplicate Envoy xDS objects. Currently, as POC we are creating both IPv4 and IPv6 listeners, which for HTTP need to map to IPv4 and IPv6 routes. These routes are identical except they point to different named clusters and domains have IPv4 or IPv6 cluster IP in them. These IPv4/v6 clusters are also identical with the primary difference that the endpoints associated with them have the correct IP family address. In theory, this all works but seems wasteful and feels like there should be a better way to do it which we might be missing.

I couldn't find any existing Envoy solutions to avoid duplication, so discussing with other folks in Istio community we wanted to explore this option of enhancing Envoy to pick the appropriate upstream endpoint address (IP family) based on the downstream connection. If this seems totally crazy, I'm happy to learn a better way to avoid this config duplication.

nrjpoddar commented 3 years ago

cc @howardjohn @jacob-delgado @ycai-aspen @lambdai

mattklein123 commented 3 years ago

cc @alyssawilk

For upstream, @alyssawilk and team are working on the ability to handle dual stack. For downstream, I would like to implement https://github.com/envoyproxy/envoy/issues/11184 which would allow a listener to bind to multiple addresses.

nrjpoddar commented 3 years ago

cc @alyssawilk

For upstream, @alyssawilk and team are working on the ability to handle dual stack. For downstream, I would like to implement #11184 which would allow a listener to bind to multiple addresses.

Thanks @mattklein123. We were planning to use ipv4 compatibility flag on listeners which can help in avoiding duplication for wildcard addresses. But multiple actresses on a listener can remove duplication for specific addresses too so thank you for the pointer!

@alyssawilk can you share any docs/PRs for upstream dual-stack handling?

alyssawilk commented 3 years ago

We don't have docs yet, but it's part of the work @RyanTheOptimist and I are doing on general failover for upstream: right now we're focused on HTTP/3 failing over to TCP, but happy-eyeballs IPv6/IPv4 handling is likely coming next.

lambdai commented 3 years ago

What are the critical features if we need mixed ipv4 and ipv6 endpoints in Cluster ?

I can remember an ip bind. We don't want to bind an ipv4 address if the remote ip is ipv6.

I proposed automatic bind in the past https://github.com/envoyproxy/envoy/issues/9811 . It should be a minor change. I guess there was no motivation but now it's the time to implement

alyssawilk commented 3 years ago

I would think that Envoy would do the right thing with 2 hosts in a cluster, one of which was IPv4 and the other Ipv6. We're more focused on dynamic forward proxy, where some endpoints may have v4 and v6 resolution, and on the open internet, ipv6 may not work on some networks.

alyssawilk commented 3 years ago

FWIW filed https://github.com/envoyproxy/envoy/issues/16309 for the bits I mentioned above

github-actions[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

github-actions[bot] commented 3 years ago

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.