TIP-549: P2P support IPv6 protocol

[317787106]

TIP: 549
Title: P2P support IPv6 protocol
Author: [email protected]
Status: Final
Type: Standards Track
Category: Networking
Created: 2023-05-22

Simple Summary

This document describes how to support nodes with IPv6 stack in libp2p network.

Abstract

Libp2p support connection between IPv6 nodes to expand usage scenarios and provide adaptability, we prefer to use IPv4 to be suitable for most scenarios if nodes supoort both IPv4 and IPv6.

Motivation

IPv6 has some major advantages over IPv4:

1. Larger address space. IPv6 uses 128-bit addresses, giving it a huge address space of 2^128 addresses. In contrast, IPv4 only has 32-bit addresses, and the address space is nearly depleted.
2. No more NAT (Network Address Translation). IPv6 eliminates the need for NAT and its problems. NAT is required in IPv4 due to the limited address space.
3. Better security. IPv6 supports IPSec (IP Security) as a core part of its specifications. IPSec provides features like authentication, encryption, and anti-replay protection. IPv4 also supports IPSec but as an add-on specification.
4. Simplified header format. IPv6 has a simplified header format compared to IPv4. The IPv6 header does not have options and is a fixed size of 40 bytes. The IPv4 header has options and is variable in size.
5. Auto-configuration. IPv6 supports stateless address autoconfiguration. This means when an IPv6 device boots up, it can configure its own address and network settings without needing a DHCP server.
6. Faster routing. The simplified IPv6 header and hierarchical network design allow for more efficient routing table lookups and faster routing.
7. Mobility support. IPv6 has improved support for mobile devices which frequently change networks. IPv6 allows a mobile device to move from one network to another without changing its IP address.
8. Multicasting. IPv6 supports multicasting much more extensively than IPv4. Multicasting allows for more efficient use of network resources when sending data to multiple destinations.
9. Transition mechanism from IPv4. IPv6 provides mechanisms that allow IPv6 to co-exist with IPv4 during the transition between the two versions. This allows for gradual migration from IPv4 to IPv6.

Those are some of the major advantages of IPv6 over IPv4. IPv6 is the future of the Internet and support for IPv6 is growing steadily. So libp2p should support nodes with IPv6.

Specification

If a node supports dual IP protocol stacks and does not specify a listening IP when starting a UDP or TCP server, then both IPv4 and IPv6 ports are open at the same time, and both IPv4 and IPv6 connections can be accepted at the same time. IPv6 only refers to WAN IPv6, don't include LAN IPv6. Generally, nodes with IPv4 addresses and nodes with IPv6 addresses cannot connect because the packet headers are inconsistent. Unless the IPv4 network actively accesses the IPv6 network through NAT64 static mapping.

IP Stack Preference

Each node can be represented:

message Endpoint {
  bytes address = 1; //IPv4
  int32 port = 2;
  bytes nodeId = 3;
  bytes addressIpv6 = 4; //IPv6
}

We prefer to use IPv4 if a node support both IPv4 & IPv6. This is the UDP & TCP connection preference between two nodes:

	B supports IPv4 only	B supports IPv6 only	B supports IPv4 & IPv6
A supports IPv4 only	IPv4	Can not connect	IPv4
A supports IPv6 only	Can not connect	IPv6	IPv6
A supports IPv4 & IPv6	IPv4	IPv6	IPv4

We consider three steps that how IP stack works in libp2p.

Step 1: Address exchange & synchronization (UDP)

Suppose nodes A and B both support IPv4 and IPv6. Node B has configured Node A's IPv6 in its seed node.

1. B constructs Node A from the seed node, which only has an IPv6 address; method getNodeHandler in KadService generates a new NodeHandler based on Node A; sends a ping to A through IPv6, and the ping message contains 2 addresses of B;
2. After receiving B's ping which contains B's complete 2 addresses, A generates Node B and generates a new NodeHandler; A sends a pong message to B through IPv6, containing A's 2 complete addresses; (ping and pong must apply the same protocol stack)
3. B receives A's pong message, getNodeHandler finds that it exists according to the key generated by Node A, and updates Node A by filling in A's IPv4 address;

The key point is how node deduplicates and updates the IP according to the key. If exists a node P with a dual IP protocol stack, for any other node Q, there are only four possible received sequences to know P:

• Node(IPv4, IPv6) → Node(IPv4, null)
• Node(IPv4, IPv6) → Node(null, IPv6)
• Node(IPv4, null) → Node(IPv4, IPv6)
• Node(null, IPv6) → Node(IPv4, IPv6)

If the following two situations occur, they cannot be recognized as the same Node:

• Node(IPv4, null) → Node(null, IPv6)
• Node(null, IPv6) → Node(IPv4, null)

Therefore, do not add a node's IPv4 and IPv6 at the same time in the configuration file. Otherwise, it may not be recognized as the same node and cannot be deduplicated.

Step 2: Find neighbors (UDP)

Following the last step, B finds that A supports dual protocol stacks, and also supports dual protocol stacks itself. According to the IPv4 priority principle, send a FindNeighbor message to A through IPv4.

After receiving the FindNeighbor message, A finds that nodeHandler already exists according to the key obtained by Node. When sending a Neighbor packet, the IP stack sent must be consistent with the IP stack received.

Let's suppose other conditions.

Case 1: Assume that node A has dual protocol stacks and node B only supports IPv6. Node B starts the server and includes A's IPv6 address in its seed list.

For compatibility reasons, the two Nodes can only communicate through IPv6.

Case 2: Both A and B are dual-stack nodes, and B obtains node A from other nodes' Neighbor packets. Since IPv4 is preferred, all packets go through the IPv4 protocol stack.

Step 3: TCP connection

1. The method getConnectableNodes of class KadService must filter nodes with incompatible IP stacks.
2. The method getNodes of class ConnPoolService deduplicates according to the dual-protocol stack: If the IPv4+port of a node is already in use, the corresponding IPv6+port must be filtered out to prevent connecting with the same node twice.
3. Connect Priority:
   • If it supports IPv4 itself and other nodes also support IPv4, use IPv4; otherwise:
   • If it only supports IPv6 itself, and other nodes also support IPv6, then use IPv6.
   • Other conditions do not exist

Other

1. How to find out whether my node supports IPv6?

You can use this command to get your WAN IPv6, not including the LAN address, such as loopback, etc.:

curl https://v6.ident.me

2. How to express IPv6 in config file?

You should use [IPv6]:port or IPv4:port in the config file.

3. How to test IPv6 connection?

ping6 -c4 2600:1f13:908:1b00:e1fd:5a84:251c:a32a

Or

telnet -6 2600:1f13:908:1b00:e1fd:5a84:251c:a32a 18888

4. How to use IPv6 in java-tron?

Use code version v4.7.2 or later and config this item in config.conf.

node.enableIpv6 = true //default false

[Jamestepfoward]

basically, this issue is to enable the IPV6 address supported by Libp2p, but as introduced a lot of advantages of IPV6, why still prefer IPV4 when two nodes support both IPV4 and IPV6?

[317787106]

The main purpose of supporting IPv6 is to expand the applicability of libp2p. All fullnodes of java-tron support IPv4 now, we should first meet the current demand. We might be able to specify the priority manually later.

[Bellgin]

So all nodes will let both IPv4 and IPv6 ports standby by default?

[Jamestepfoward]

The main purpose of supporting IPv6 is to expand the applicability of libp2p. All fullnodes of java-tron support IPv4 now, we should first meet the current demand. We might be able to specify the priority manually later.

Well, as long as there is IPV6 and IPV6 connection such as A and B only support IPV6, it should be compatible with the whole network, this answer does not really convince me of not using IPV6 if A and B all support dual IP stack.

[317787106]

So all nodes will let both IPv4 and IPv6 ports standby by default?

I don't quite understand what you mean, can you explain it ?

[WalterBrooks]

The main purpose of supporting IPv6 is to expand the applicability of libp2p. All fullnodes of java-tron support IPv4 now, we should first meet the current demand. We might be able to specify the priority manually later.

Well, as long as there is IPV6 and IPV6 connection such as A and B only support IPV6, it should be compatible with the whole network, this answer does not really convince me of not using IPV6 if A and B all support dual IP stack.

Hi, I think this issue just meant to add support to IPV6 at the first time, whether it works steady or fragile is hard to tell now. However IPV4 has been proved to be trusted. That's why it is not widely adopted so far, if IPV6 connection works well, I suppose the dev will consider to switch all connection to IPV6 if node supports.

[Ocea91]

@WalterBrooks Totally agreed. As a config item in the client of a decentralized network, no one can make sure all nodes enable IPv6 in succession or whatever, but the devs have to guarantee the network keeps running without exceptions. IPv4 does that, no matter the other node support which stack, but IPv6 does not. It is an ongoing business, they have to make sure IPv6 works perfectly, and then mandatory updates could make all nodes support IPv6.

[SevenPie-R58zz]

Supporting IPv6 is indeed a modern and trendy idea. Just have one small question, if IPv6 has so many benefits, why still prefer IPv4 when both nodes support IPv6 & IPv4?

[317787106]

Close this issue as it is implemented by GreatVoyage-v4.7.2.
https://github.com/tronprotocol/tips/blob/master/tip-549.md
Check implementation PR at tronprotocol/libp2p#4, tronprotocol/libp2p#39