Duke Leto
3 years ago
1 changed files with 181 additions and 0 deletions
@ -0,0 +1,181 @@ |
|||
<pre> |
|||
HIP: 155 |
|||
Layer: Peer Services |
|||
Title: addrv2 message |
|||
Author: Duke Leto |
|||
Status: Draft |
|||
Type: Standards Track |
|||
</pre> |
|||
|
|||
# Introduction |
|||
|
|||
## Abstract |
|||
|
|||
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 <code>addr</code> message. |
|||
|
|||
|
|||
## Motivation |
|||
|
|||
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 |
|||
<ref>[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt Tor Rendezvous Specification - Version 3]</ref>. |
|||
These services have 256 bit addresses and thus do not fit in the existing <code>addr</code> message, which encapsulates onion addresses in OnionCat IPv6 addresses. |
|||
|
|||
Other 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. |
|||
|
|||
# Specification |
|||
|
|||
<blockquote> |
|||
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<ref>[https://tools.ietf.org/html/rfc2119 RFC 2119]</ref>. |
|||
</blockquote> |
|||
|
|||
The <code>addrv2</code> message is defined as a message where <code>pchCommand == "addrv2"</code>. |
|||
It is serialized in the standard encoding for P2P messages. |
|||
Its format is similar to the current <code>addr</code> message format |
|||
<ref>[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer Reference: addr message]</ref>, with the difference that the |
|||
fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize]. |
|||
|
|||
This means that the message contains a serialized <code>std::vector</code> of the following structure: |
|||
|
|||
{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" |
|||
!Type |
|||
!Name |
|||
!Description |
|||
|- |
|||
| <code>uint32_t</code> |
|||
| <code>time</code> |
|||
| Time that this node was last seen as connected to the network. A time in Unix epoch time format. |
|||
|- |
|||
| <code>CompactSize</code> |
|||
| <code>services</code> |
|||
| Service bits. A bit field that is 64 bits wide, encoded in [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize]. |
|||
|- |
|||
| <code>uint8_t</code> |
|||
| <code>networkID</code> |
|||
| Network identifier. An 8-bit value that specifies which network is addressed. |
|||
|- |
|||
| <code>std::vector<uint8_t></code> |
|||
| <code>addr</code> |
|||
| Network address. The interpretation depends on networkID. |
|||
|- |
|||
| <code>uint16_t</code> |
|||
| <code>port</code> |
|||
| Network port. If not relevant for the network this MUST be 0. |
|||
|} |
|||
|
|||
One message can contain up to 1,000 addresses. Clients SHOULD reject messages with more addresses. |
|||
|
|||
Field <code>addr</code> has a variable length, with a maximum of 512 bytes (4096 bits). |
|||
Clients SHOULD reject messages with longer addresses, irrespective of the network ID. |
|||
|
|||
The list of reserved network IDs is as follows: |
|||
|
|||
{| class="wikitable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;" |
|||
!Network ID |
|||
!Enumeration |
|||
!Address length (bytes) |
|||
!Description |
|||
|- |
|||
| <code>0x01</code> |
|||
| <code>IPV4</code> |
|||
| 4 |
|||
| IPv4 address (globally routed internet) |
|||
|- |
|||
| <code>0x02</code> |
|||
| <code>IPV6</code> |
|||
| 16 |
|||
| IPv6 address (globally routed internet) |
|||
|- |
|||
| <code>0x03</code> |
|||
| <code>TORV2</code> |
|||
| 10 |
|||
| Tor v2 hidden service address |
|||
|- |
|||
| <code>0x04</code> |
|||
| <code>TORV3</code> |
|||
| 32 |
|||
| Tor v3 hidden service address |
|||
|- |
|||
| <code>0x05</code> |
|||
| <code>I2P</code> |
|||
| 32 |
|||
| I2P overlay network address |
|||
|- |
|||
| <code>0x06</code> |
|||
| <code>CJDNS</code> |
|||
| 16 |
|||
| Cjdns overlay network address |
|||
|} |
|||
|
|||
Clients are RECOMMENDED to gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and make it more difficult for an observer to tell which networks a node is connected to. |
|||
|
|||
Clients SHOULD NOT gossip addresses from unknown networks because they have no means to validate those addresses and so can be tricked to gossip invalid addresses. |
|||
|
|||
Further network ID numbers MUST be reserved in a new BIP document. |
|||
|
|||
Clients SHOULD reject messages that contain addresses that have a different length than specified in this table for a specific network ID, as these are meaningless. |
|||
|
|||
See the appendices for the address encodings to be used for the various networks. |
|||
|
|||
==Signaling support and compatibility== |
|||
|
|||
Introduce a new message type <code>sendaddrv2</code>. Sending such a message indicates that a node can understand and prefers to receive <code>addrv2</code> messages instead of <code>addr</code> messages. I.e. "Send me addrv2". |
|||
|
|||
The <code>sendaddrv2</code> message MUST only be sent in response to the <code>version</code> message from a peer and prior to sending the <code>verack</code> message. |
|||
|
|||
For older peers, that did not emit <code>sendaddrv2</code>, keep sending the legacy <code>addr</code> message, ignoring addresses with the newly introduced address types. |
|||
|
|||
# Reference implementation |
|||
|
|||
The reference implementation is available at (to be done) |
|||
|
|||
# Acknowledgements |
|||
|
|||
- BIP155 |
|||
|
|||
## Appendix A: Tor v2 address encoding |
|||
|
|||
The new message introduces a separate network ID for <code>TORV2</code>. |
|||
|
|||
Clients MUST send Tor hidden service addresses with this network ID, with the 80-bit hidden service ID in the address field. This is the same as the representation in the legacy <code>addr</code> message, minus the 6 byte prefix of the OnionCat wrapping. |
|||
|
|||
Clients SHOULD ignore OnionCat (<code>fd87:d87e:eb43::/48</code>) addresses on receive if they come with the <code>IPV6</code> network ID. |
|||
|
|||
## Appendix B: Tor v3 address encoding |
|||
|
|||
According to the spec <ref>[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt Tor Rendezvous Specification - Version 3: Encoding onion addresses]</ref>, next-gen <code>.onion</code> addresses are encoded as follows: |
|||
<pre> |
|||
onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion" |
|||
CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2] |
|||
|
|||
where: |
|||
- PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service |
|||
- VERSION is a one byte version field (default value '\x03') |
|||
- ".onion checksum" is a constant string |
|||
- CHECKSUM is truncated to two bytes before inserting it in onion_address |
|||
- H() is the SHA3-256 cryptographic hash function |
|||
</pre> |
|||
|
|||
Tor v3 addresses MUST be sent with the <code>TORV3</code> network ID, with the 32-byte PUBKEY part in the address field. As VERSION will always be '\x03' in the case of v3 addresses, this is enough to reconstruct the onion address. |
|||
|
|||
# Appendix C: I2P address encoding |
|||
|
|||
Like Tor, I2P naming uses a base32-encoded address format<ref>[https://geti2p.net/en/docs/naming#base32 I2P: Naming and address book]</ref>. |
|||
|
|||
I2P uses 52 characters (256 bits) to represent the full SHA-256 hash, followed by <code>.b32.i2p</code>. |
|||
|
|||
I2P addresses MUST be sent with the <code>I2P</code> network ID, with the decoded SHA-256 hash as address field. |
|||
|
|||
## Appendix D: Cjdns address encoding |
|||
|
|||
Cjdns addresses are simply IPv6 addresses in the <code>fc00::/8</code> range<ref>[https://github.com/cjdelisle/cjdns/blob/6e46fa41f5647d6b414612d9d63626b0b952746b/doc/Whitepaper.md#pulling-it-all-together Cjdns whitepaper: Pulling It All Together]</ref>. They MUST be sent with the <code>CJDNS</code> network ID. |
|||
|
|||
## References |
|||
|
|||
<references/> |
Loading…
Reference in new issue