IPv6 support

[fengli79]

Does envoy support IPv6? If not, is there a plan to support it?

[mattklein123]

It took a lot longer to have this issue opened than I thought it would. 😉

It's not currently supported. It wouldn't be difficult to support, but someone needs to do the work.

[jamessynge]

Can you provide any pointers to where support is missing (e.g. int fields for addresses, or parsing of only IPv4 addresses)?

[fengli79]

Here's an example:
https://github.com/lyft/envoy/blob/c36bb76e304ab4c5584a07303e2953a170888319/source/common/network/listener_impl.cc#L104

And if you search AF_INET6 in the repo, there's no reference.

[mattklein123]

This is somewhat related to #390 which I am going to fix soon (next week most likely).

In general, it depends on where we need/want IPv6 support. There will be a small number of changes sprinkled through the code base, and not all of them are necessarily needed at once:

1. Add IPv6 listener support
2. Add IPv6 proxy proto support
3. Add IPv6 address parsing support for upstream connections, logging, etc.
4. Add IPv6 IP list support (for white lists, TCP proxy routing, etc.)

I would like to wait until #390 is done before taking this on. Also if we could get crisp about which scenarios people want explicitly, that would be great, and I can point you in the right direction if you want to work on this.

[mattklein123]

#390 is done. This should be pretty straightforward at this point if someone wants to take this on.

[jamessynge]

I'll take a look on Monday.

…

On Fri, Feb 10, 2017 at 10:26 PM, Matt Klein ***@***.***> wrote: #390 <#390> is done. This should be pretty straightforward at this point if someone wants to take this on. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#351 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYmU5ipuuxHM2q8z26GKcCX5IthIj9Vks5rbSpdgaJpZM4LiQ9h> .

[jamessynge]

FYI, I'm going to start with adding some tests, e.g. for common/network/listener, that use IPv6 loopback rather than IPv4 loopback.

[jamessynge]

For "class Ipv6" (analagous to Network::Address::Ipv4), is it OK to use a struct such as in6_addr, as the return type for the address, or is there a preference to avoid using platform specific headers in this code?

[mattklein123]

IIRC we don't even need that right now. The only place that would be required is if/when we implement IPv6 address/mask matching in IpList, which isn't necessarily required for v1 of IPv6 support. Optimally, it would be nice to not expose system types (just thinking about eventual NT port), but given how infrequently that data will be used, it's fine if you want to do that for now.

[jamessynge]

ProxyProtocol::ActiveConnection::onReadWorker reads an IPv4 range from somewhere (apparently not the json config file), and then passes it to Network::IpList, which only handles IPv4. Having reviewed the protocol, it looks like it should also be extended to support IPv6. Agreed?

More generally, I suspect that I should convert IpList to handle IPv4 and IPv6 addresses, though perhaps with some option to limit which is allowed on any one call.

[mattklein123]

ProxyProtocol::ActiveConnection::onReadWorker reads an IPv4 range from somewhere (apparently not the json config file), and then passes it to Network::IpList, which only handles IPv4. Having reviewed the protocol, it looks like it should also be extended to support IPv6. Agreed?

Sorry not following. Did you link the wrong function? The proxy proto code just implements http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt. It would be nice to make this work for IPv6 at some point.

More generally, I suspect that I should convert IpList to handle IPv4 and IPv6 addresses, though perhaps with some option to limit which is allowed on any one call.

Yes, IpList is currently used in both tcp_proxy routing as well as client_ssl auth white listing. It would be great to make this work for IPv6 in both cases.

In general though, I don't think you need to do a single giant PR to add IPV6 support everywhere. (And in fact I would recommend you don't). There are a bunch of separate places where we can add IPv6 support and test:

• Downstream listener IPv6
• DNS IPv6
• Upstream IPv6
• IpList IPv6
• ProxyProto IPv6

[jamessynge]

Agreed, I was planning that the current PR would be separate from adding support elsewhere.

Ignore what I said about ProxyProtocol, I was a bit confused when I started writing that.