BIP: ??? Layer: Peer Services Title: addrv2 message Author: Wladimir J. van der Laan <laanwj@gmail.com> Comments-Summary: No comments yet. Comments-URI: Status: Draft Type: Standards Track Created: 2018-06-01 License: BSD-2-Clause
This document proposes a new P2P message to gossip longer node addresses over the P2P network. This is required to support new-generation Onion addresses, I2P, and potentially other networks that have longer endpoint addresses than fit in the 128 bits of the current `addr` message.
This BIP is licensed under the 2-clause BSD license.
Tor v3 hidden services are part of the stable release of Tor since version 0.3.2.9. They have various advantages compared to the old hidden services, among which better encryption and privacy [1]. These services have 256 bit addresses and thus do not fit in the existing `addr` message, which encapsulates the onion addresses in IPv6 addresses.
Other alternative transport-layer protocols such as I2P have always used longer addresses. This change would make it possible to gossip such addresses over the P2P network, so that other peers can connect to them.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[2].
The addrv2 message is defined as a message where pchCommand == "addrv2".
It is serialized in the standard format for P2P messages.
The format is similar to the current addr message format
[3], with the difference that the
fixed 16-byte IP address is replaced by a network ID and a variable-length address:
| Type | Name | Description |
|---|---|---|
| uint32_t | time | Time that this node was last seen as connected to the network. |
| uint64_t | services | Service bits. |
| uint8_t | networkID | Network identifier. This specifies which network is addressed. |
| std::vector<uint8_t></uint8_t> | addr | Network address (interpretation depends on networkID). |
| uint16_t | port | Network port. If not relevant for the network this MUST be 0. |
Addresses have a variable length, with a maximum of 32 bytes (256 bits). Clients SHOULD reject longer addresses.
To allow for future extensibility, clients MUST ignore address types that they do not know about. Client MAY gossip address formats that they do not know about.
A list of reserved network IDs follows:
| Network ID | Enumeration | Length (bytes) | Description |
|---|---|---|---|
| 0x01 | IPV4 | 4 | IPv4 address |
| 0x02 | IPV6 | 16 | IPv6 address |
| 0x03 | TORV2 | 16 | Tor v2 hidden service address |
| 0x04 | TORV3 | 32 | Tor v3 hidden service address |
| 0x05 | I2P | 32 | I2P overlay network address |
- Old clients will ignore the `addrv2` message, so using `addrv2` format for only the larger addresses (TORV3, I2P) wwould naturally preserve backward compatibility.
- Another option would be to use `addrv2` messages only above a certain protocol version.
- ^ https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt
- ^ RFC 2119
- ^ Bitcoin Developer Reference: addr message
The reference implementation is available at ...