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

IPv6 Support #400

Closed
CMCDragonkai opened this issue Jul 7, 2022 · 9 comments
Closed

IPv6 Support #400

CMCDragonkai opened this issue Jul 7, 2022 · 9 comments
Assignees
Labels
development Standard development r&d:polykey:core activity 4 End to End Networking behind Consumer NAT Devices

Comments

@CMCDragonkai
Copy link
Member

CMCDragonkai commented Jul 7, 2022

Specification

IPv4 is being exhausted, and much of the new internet will be ipv6 only.

The PK agent should support binding, listening and connecting to IPv6 addresses.

Currently we're limited in several ways:

  1. The utp-native has no IPv6 support
  2. NAT busting hasn't been tested with IPv6 (what kind of NAT architectures would exist for IPv6)
  3. DHT hasn't been tested with IPv6
  4. CLI option parsing hasn't been tested with IPv6
  5. Our AWS NLB which runs the testnet and mainnet does not yet support IPv6 with UDP protocol
  6. AWS VPC/subnets hasn't been tested with IPv6 or configured with IPv6 assignments
  7. Our GRPC server (and perhaps client service in general) hasn't been tested with dual stack assignments, supporting IPv6 means we should still listen on IPv4 at the same time (but this requires documentation of the options)

All of the above has to be solved to support IPv6.

Additional context

Tasks

  1. Add tests to Node Connection to test local IPv6 usage
  2. Enable IPv6 on the testnet
  3. Apply integration tests to the testnet infrastructure
  4. IPv6 supported by quic layer.
  5. IPv6 supported by websocket layer.
  6. IPv6 discovery with MDNS.
  7. IPv6 supported by nodeGraph.
@CMCDragonkai
Copy link
Member Author

RPC is no longer limited to IPv4, it can do IPv4 or IPv6.

The question of IPv6 is actually more pertinent to QUIC or WebSockets, however I think these should work without any problems.

More testing is required for the nodes domain to ensure that IPv6 is working too.

We're no longer using any load balancer in AWS.

@tegefaulkes can add more details here.

@tegefaulkes
Copy link
Contributor

The agnostic RPC doesn't care about transport so long as it's a bi-directional UInt8Array. So yeah, the IPv6 support comes down to the websocket and quic implementations. I think both should be able to support it.

@CMCDragonkai CMCDragonkai added the r&d:polykey:core activity 4 End to End Networking behind Consumer NAT Devices label Jul 10, 2023
@CMCDragonkai
Copy link
Member Author

Testing for IPv6 is relevant for agent migration.

@CMCDragonkai
Copy link
Member Author

Isn't this part of the agent migration @tegefaulkes?

@tegefaulkes
Copy link
Contributor

I can add it to #535 , Though I think IPv6 support is added by just using js-quic now. So it's something to check.

@tegefaulkes
Copy link
Contributor

For this to be considered done, we'd need to support IPv6 on every level. We need to track the IPv6 address in the nodeGraph. Possibly as part of #537. The websocket transport layer needs to support it, I think it can so likely that's a simple change. Lastly we'd want to discover 'local' IPv6 addresses with the MDNS system.

@CMCDragonkai
Copy link
Member Author

So one thing I'm doing is aligning up the network configuration since it's currently quite confusing.

      // Using `localhost` defaults to OS configuration
      agentHost: 'localhost',
      agentPort: 0,
      // Using `localhost` defaults to OS configuration
      clientHost: 'localhost',
      clientPort: 0,
      // If using dual stack `::`, this forces only IPv6
      ipv6Only: false,

So originally this was set to 127.0.0.1 because we only had IPv4 support.

Now with both websockets and QUIC supporting IPv6, we should default to dual stack right?

Now only :: is dual stack. The other designations are not automatically dualstack. This is just how nodejs worked.

Now there's another problem. Polykey is by default a distributed and decentralised system.

I just checked the default values set on Polykey-CLI and this is set to whatever is the default network configuration.

That would mean when users launch PK, they launch only binding to localhost. That won't work at all!

Instead we need to understand that by default agentHost should be ::, whereas by default clientHost should be localhost.

This provides secure defaults for the client service while also maintaining that the agentHost is supposed to be public.

Next the ipv6Only option should control both the client service and the agent service. And also note that it would only ever activate if :: is the binding that is being used.

@CMCDragonkai
Copy link
Member Author

Both js-quic and js-ws will be ipv6 native, in fact dual stack native!

@CMCDragonkai
Copy link
Member Author

WS and QUIC are both integrated. We should test ipv6 support on PK CLI @tegefaulkes. I'm going to close this for now, because technically PK underlying code should fully support it, however node graph fixes may be required. Task 7 that is. We do it under #551.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development Standard development r&d:polykey:core activity 4 End to End Networking behind Consumer NAT Devices
Development

No branches or pull requests

2 participants