add ipv6-only mode

[rpodgorny]

this would:

1. allow me to test the future-proof-ness of ipfs
2. possibly solve the "that many connections just fill the nat table on my router making internet unusable for everyone" problem
3. ...others? ;-)

[aschmahmann]

I don't see a particularly strong reason to do this with go-ipfs as a binary since it's basically just for testing and could lead to adverse effects on the public DHT if users ran their nodes in "auto" (the default) or "server" modes and would likely lead to poorer public DHT lookups in all modes including "client".

However, libp2p already supports doing this via announce addresses + connection gating so if you'd like to do this using go-ipfs as a library you already can.

If you do so I highly recommend doing one of :

1. run the DHT in client mode (or turning it off)
2. run a private network
3. run a forked DHT (i.e. change the protocol prefix to be /mynetwork)

[Stebalien]

You can do this by:

1. Removing the default /ip4 listen addresses.
2. Adding "/ip4/0.0.0.0/ipcidr/0" to Swarm.AddrFilters.

[rpodgorny]

You can do this by:

1. Removing the default `/ip4` listen addresses.

2. Adding `"/ip4/0.0.0.0/ipcidr/0"` to [`Swarm.AddrFilters`](https://github.com/ipfs/go-ipfs/blob/master/docs/config.md#swarmaddrfilters).

thanks for the hint - that's what i've basically done. also, one needs to change the api and gateway listen addresses...

but all in all, it's quite cumbersome and somewhat error prone. also, a "quick switch" is only achieved only by having two configs with lots of duplicate settings and switching between them back and forth.

but i also understand that such feature (command line option to turn off ipv4 completely) may be not interesting for most ipfs users and could end up being a feature creep... ...so, you decide. ;-)

[Stebalien]

Yeah. Unfortunately, this is a really edge-case feature that's not too difficult to achieve otherwise.

If you wanted to test IPFS without IPv4, I'd recommend just disabling IPv4 at the OS level. In terms of NATs... unfortunately I'm pretty sure most NATs will track IPv6 connections anyways.

[dbeal-eth]

one thing I will mention is that some IP providers have started sharding individual IPv4 addresses into hundreds of shards, giving each internet customer only about 200 ports. this means that if your running IPFS or another P2P service on a network subject to this type of restriction, IPFS will consume all available IPv4 ports and cause the internet connection to be unstable.

[bumblefudge]

one thing I will mention is that some IP providers have started sharding individual IPv4 addresses into hundreds of shards, giving each internet customer only about 200 ports.

but all in all, it's quite cumbersome and somewhat error prone. also, a "quick switch" is only achieved only by having two configs with lots of duplicate settings and switching between them back and forth.

It probably doesn't justify the complexity of "profiles" in the CID sense, but couldn't libp2p implement some kind of config flags that could be inherited by kubo? --ipv6-only and --max-multicast=100 both seem like reasonable env vars/config flags to be able to declare at runtime/daemon-instantiation-time...