Standardization of multiple IP stacks IPv6/IPv4

[pierresouchay]

Issue description

We are currently moving progressively towards IPv6 in our datacenters.

I was wondering if there were some recommendations to enable Consul providing both IPv4 and IPv6 addresses for those cases.

We did not see anything regarding this in the documentation and while it might be possible to declare services instances twice with 2 different addresses, this is a bit complicated and might cause issues with non IPv6 aware systems.

Applications relying on Consul to discover instances usually have to look if Service.Address is set and if not, will lookup at the Node.Address value. I was wondering it if would be possible to delare additionnal addresses in a standardized way, so client would all use the same mechanism.

While it might be possible to achieve the same result with Service.Meta and Node.Meta, the downside is that no Standardization is done, so all SDKs implementing Consul Discovery would not benefit from it.
Furthermore, declaring IPv6 in node meta would not in in DNS (regarding A/AAAA queries as well as regarding reverse DNS queries - which is useful for Kerberized systems for instance).

Possible solution

Thus I was wondering if a PR doing this would be acceptable:

Add optional fields for Node/Service called Address_IPv4 and Address_IPv6 to Consul Nodes and Consul Services (if you think migration to IPv4 might not make sense, do not implement Address_IPv4). Thus a caller to Consul a Consul endpoint might choose to use Address_IPv6 instead of Address if the field is set. When performing DNS queries, if ANY, return the preferred (aka Address), when performing A/AAAA, use the preferred if if matches IP version requested in the query, otherwise, try to get a look a Address_IPv6/Address_IPv4 if defined.

So basically, health might give this kind of output (assuming all fields are
set including in Services):

"Node" {
    "Address": "192.168.1.1",
    "Address_IPv6": "192.168.3.16"
},
"Service": {
    "Address": "192.168.1.1",
    "Address_IPv6": "192.168.3.16"
}

Note: HandlingAddress_IPv4` is really opional for us, and I think if would make sense to barely ignoring it.

What do you think?
Would you accept such PR (with changes if you prefer) if we could provide it ?

[mkeeler]

@pierresouchay An alternative to this I was pondering recently would be to reuse the tagged addresses on both the node as well as services to allow specifying the following addresses:

• LAN - default lan address
• LAN_IPv4 - default lan IPv4 address
• LAN_IPv6 - default lan IPv6 address
• WAN - default wan address
• WAN_IPv4 - default wan IPv4 address
• WAN_IPv6 - default wan IPv6 address

There is already a BestAddress method implemented for many of the service discovery types: Node, NodeService, CheckServiceNode. It currently takes into account all the available addresses and whether a wan address is preferred. We could then update those methods to take into account whether an IPv4 or an IPv6 address is being requested and return the desired one. We would of course need to modify the translation logic in a few places (DNS server being the big one) to request the desired address type.

[pierresouchay]

@mkeeler Yes, I did not think about re-using. it for something different than lan/wan (and I actually did not know/forgot that Service structure did support this as well). That's so better!

We'll try to come up with a patch quickly to address that. Thank you so much!

[mkeeler]

Closing this as I merged #6640 a moment ago.