ENR structure: Add tcp6, quic6 and udp6.

[nalepae]

As discussed in ACDC#139.

This PR is draft until #3644 is merged.

[jxs]

we probably should also update

consensus-specs/specs/phase0/p2p-interface.md

Lines 121 to 137 in f4e3908

	### Transport
	Even though libp2p is a multi-transport stack (designed to listen on multiple simultaneous transports and endpoints transparently),
	we hereby define a profile for basic interoperability.
	All implementations MUST support the TCP libp2p transport, and it MUST be enabled for both dialing and listening (i.e. outbound and inbound connections).
	The libp2p TCP transport supports listening on IPv4 and IPv6 addresses (and on multiple simultaneously).
	Clients must support listening on at least one of IPv4 or IPv6.
	Clients that do _not_ have support for listening on IPv4 SHOULD be cognizant of the potential disadvantages in terms of
	Internet-wide routability/support. Clients MAY choose to listen only on IPv6, but MUST be capable of dialing both IPv4 and IPv6 addresses.
	All listening endpoints must be publicly dialable, and thus not rely on libp2p circuit relay, AutoNAT, or AutoRelay facilities.
	(Usage of circuit relay, AutoNAT, or AutoRelay will be specifically re-examined soon.)
	Nodes operating behind a NAT, or otherwise undialable by default (e.g. container runtime, firewall, etc.),
	MUST have their infrastructure configured to enable inbound traffic on the announced public listening endpoint.

to state that clients may support QUIC right?

[AgeManning]

we probably should also update

consensus-specs/specs/phase0/p2p-interface.md

Lines 121 to 137 in f4e3908

	### Transport
	Even though libp2p is a multi-transport stack (designed to listen on multiple simultaneous transports and endpoints transparently),
	we hereby define a profile for basic interoperability.
	All implementations MUST support the TCP libp2p transport, and it MUST be enabled for both dialing and listening (i.e. outbound and inbound connections).
	The libp2p TCP transport supports listening on IPv4 and IPv6 addresses (and on multiple simultaneously).
	Clients must support listening on at least one of IPv4 or IPv6.
	Clients that do _not_ have support for listening on IPv4 SHOULD be cognizant of the potential disadvantages in terms of
	Internet-wide routability/support. Clients MAY choose to listen only on IPv6, but MUST be capable of dialing both IPv4 and IPv6 addresses.
	All listening endpoints must be publicly dialable, and thus not rely on libp2p circuit relay, AutoNAT, or AutoRelay facilities.
	(Usage of circuit relay, AutoNAT, or AutoRelay will be specifically re-examined soon.)
	Nodes operating behind a NAT, or otherwise undialable by default (e.g. container runtime, firewall, etc.),
	MUST have their infrastructure configured to enable inbound traffic on the announced public listening endpoint.

to state that clients may support QUIC right?

Yep I agree. Should add QUIC support in here

[ppopth]

This makes sense to me. I'm fine with both this PR and #3644

[jxs]

ping after #3644 got merged, this can now also be merged with the suggested updates above right?

[ppopth]

This seems like a breaking change?

Currently if some node sets ip6 and tcp, we assume that we can connect to that node with the specified IP address and TCP port?

But after this PR, specifying only ip6 and tcp doesn't make any sense? the node is supposed to specify ip6 and tcp6 instead.

I think we should ensure that all the clients have changed the logic properly before we merge this PR.

[ppopth]

@nalepae Could you undraft the PR if it's ready for review and merge?

[nalepae]

we probably should also update

consensus-specs/specs/phase0/p2p-interface.md

Lines 121 to 137 in f4e3908

	### Transport
	Even though libp2p is a multi-transport stack (designed to listen on multiple simultaneous transports and endpoints transparently),
	we hereby define a profile for basic interoperability.
	All implementations MUST support the TCP libp2p transport, and it MUST be enabled for both dialing and listening (i.e. outbound and inbound connections).
	The libp2p TCP transport supports listening on IPv4 and IPv6 addresses (and on multiple simultaneously).
	Clients must support listening on at least one of IPv4 or IPv6.
	Clients that do _not_ have support for listening on IPv4 SHOULD be cognizant of the potential disadvantages in terms of
	Internet-wide routability/support. Clients MAY choose to listen only on IPv6, but MUST be capable of dialing both IPv4 and IPv6 addresses.
	All listening endpoints must be publicly dialable, and thus not rely on libp2p circuit relay, AutoNAT, or AutoRelay facilities.
	(Usage of circuit relay, AutoNAT, or AutoRelay will be specifically re-examined soon.)
	Nodes operating behind a NAT, or otherwise undialable by default (e.g. container runtime, firewall, etc.),
	MUST have their infrastructure configured to enable inbound traffic on the announced public listening endpoint.

to state that clients may support QUIC right?

Fixed in 8ab7bc6.

[nalepae]

@nalepae Could you undraft the PR if it's ready for review and merge?

Ready for review, but added an extra commit: See #3874 (comment)

[fjl]

But after this PR, specifying only ip6 and tcp doesn't make any sense? the node is supposed to specify ip6 and tcp6 instead.

@ppopth if "tcp6" is unspecified, but "tcp" is present, the client should use it. The idea with tcp6 is just to support an alternative port on v6 when it is present.

[ppopth]

@ppopth if "tcp6" is unspecified, but "tcp" is present, the client should use it. The idea with tcp6 is just to support an alternative port on v6 when it is present.

alright, got it.