Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can not bind to ipv6 address #2210

Open
johannbarbie opened this issue Jan 4, 2021 · 3 comments
Open

can not bind to ipv6 address #2210

johannbarbie opened this issue Jan 4, 2021 · 3 comments

Comments

@johannbarbie
Copy link

johannbarbie commented Jan 4, 2021

Describe the bug

when using --listen-address=<ipv6-address> node exits with error: Error: unhandled exception: /home/pi/nimbus-eth2/vendor/nim-chronos/chronos/transports/datagram.nim(488, 13) 'remote.family == local.family' [AssertionError]

To Reproduce
Steps to reproduce the behavior:

  1. Platform details (OS, architecture): raspberry pi 4b, arm
  2. Branch/commit used: Nimbus beacon node v1.0.4-f06e6d46-stateofus
  3. Commands being executed: ./run-pyrmont-beacon-node.sh --listen-address=x:y:z:a:b:c:d:e
  4. Relevant log lines:
INF 2021-01-04 12:26:53.336+01:00 Listening to incoming network requests     topics="beacnde" tid=21683 file=nimbus_beacon_node.nim:849
INF 2021-01-04 12:26:53.336+01:00 Starting discovery node                    topics="discv5" tid=21683 file=protocol.nim:802 node=71*99f03f:unaddressable bindAddress=x:y:z:a:b:c:d:e:9000 uri=enr:-Kq4QOpMoBA5hH83ZeClgUU2_Sb6TecWqiUcoAicY3Yc10ReFOKG2WG9ptFMpe4RSz8deQlR2hZ34GQxnCrZ-02krG4Bh2F0dG5ldHOI__________-EZXRoMpA7CIeVAAAgCf__________gmlkgnY0iXNlY3AyNTZrMaECwvD6_0ZObhhVX5jfg64ekn1QeItAIg9aWl241GD-UZaDdGNwgiMog3VkcIIjKA
INF 2021-01-04 12:26:53.336+01:00 No external IP provided, this node will not be discoverable topics="discv5" tid=21683 file=protocol.nim:806

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context

  • the node is running on a 1&1 internet DS Lite internet connection. (no ipv4 available, ipv6 ports forwarded).
  • i've tried a lot of different NAT settings, all leading to node=71*99f03f:unaddressable
@kdeme
Copy link
Contributor

kdeme commented Jan 8, 2021

IPv6 is currently not (fully) supported.
As you have noticed, setting the listen-address to an ipv6 address will fail in the discovery implementation. It is on the TODO list to add also listening and sending on ipv6 (at least in discovery: status-im/nim-eth#243)
I'm not sure on the state of ipv6 support in libp2p currently (@dryajov ?)

Now, purely adding a listener on also ipv6, and sending data on ipv6 in case of ipv6 addresses in discovery is not that much work (making the whole configuration around it UX friendly however probably is). But if you truly have only an ipv6 address on your device, it would still give you much trouble as a lot of peers (most) might not be reachable over ipv6 (or at least not have it added in their ENR). You'd still need an ipv4 listener basically.

I don't know the in depth technical details of Dual-Stack Lite, but from what I understand it is ipv4 in ipv6 tunnelling, meaning your device still has ipv4 and ipv6 dual stack, but your CPE has only ipv6 and tunnels any ipv4 traffic through IPv6, which then gets NAT'ed on the service providers network end point(s) (CGN).

This would mean that you can still use ipv4 and should have such address (local however) available to listen on. Is that correct? You will probably not be reachable however as I doubt there is any "static" port forwarding available/done on that level, but I'm not sure about this.

@dryajov
Copy link
Member

dryajov commented Jan 8, 2021

I'm not sure on the state of ipv6 support in libp2p currently (@dryajov ?)

libp2p relies on chronos for low level networking and (I believe) chronos has ipv6 support (@cheatfate?), the other part of this is multiaddress support (libp2p internal address representation), which is there but not very well tested. This certainly hasn't been a priority for us.

@johannbarbie
Copy link
Author

This would mean that you can still use ipv4 and should have such address (local however) available to listen on. Is that correct?

correct

You will probably not be reachable however as I doubt there is any "static" port forwarding available/done on that level, but I'm not sure about this.

right, and I haven't found any way to request a port to be forwarded through the providers' NAT.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants