ビットコイン・インスティテュート
ビットコイン・インスティテュート
English

BIP 155 — addrv2 メッセージ

BIP（ビットコイン改善提案） GitHub · 対象日 · 登録日 · 更新日
人物： ウラジミール・ファン・デル・ラーン
P2Pネットワークプライバシー
ウラジミール・ファン・デル・ラーン（Wladimir J. van der Laan） 2019年2月27日 
  BIP: 155
  Layer: Peer Services
  Title: addrv2 message
  Authors: Wladimir J. van der Laan <laanwj@gmail.com>
  Status: Deployed
  Type: Specification
  Assigned: 2019-02-27
  License: BSD-2-Clause
  Version: 2.1.0

はじめに

概要

本文書は、P2P ネットワーク上でより長いノードアドレスをゴシップするための新しい P2P メッセージを提案する。これは、次世代の Onion アドレスや I2P、そして現行のaddrメッセージの 128 ビットに収まらないより長いエンドポイントアドレスを持ちうるその他のネットワークをサポートするために必要である。

著作権

本 BIP は 2 条項 BSD ライセンスの下でライセンスされる。

動機

Tor v3 隠しサービスは、Tor のバージョン 0.3.2.9 以降、安定版リリースの一部となっている。旧来の隠しサービスと比較して、より優れた暗号化とプライバシーなど、さまざまな利点を持つTor Rendezvous Specification - Version 3 (https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt)。これらのサービスは 256 ビットのアドレスを持つため、onion アドレスを OnionCat の IPv6 アドレスへカプセル化する既存のaddrメッセージには収まらない。

I2P などの他のトランスポート層プロトコルも、これまで常により長いアドレスを使用してきた。この変更により、そうしたアドレスを P2P ネットワーク上でゴシップし、他のピアがそれらへ接続できるようにすることが可能になる。

仕様

本文書における「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は、RFC 2119RFC 2119 (https://tools.ietf.org/html/rfc2119)に記載されるとおりに解釈される。

addrv2メッセージは、pchCommand == "addrv2"であるメッセージとして定義される。P2P メッセージ向けの標準エンコーディングでシリアライズされる。そのフォーマットは現行のaddrメッセージフォーマットに類似しているが、固定 16 バイトの IP アドレスがネットワーク ID と可変長アドレスに置き換えられている点、そして services のフォーマットが CompactSize (https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer) に変更されている点が異なる。

これは、このメッセージが以下の構造のstd::vectorをシリアライズして含むことを意味する。

型名前説明
uint32_ttimeこのノードがネットワークに接続していると最後に確認された時刻。Unix エポック時刻形式。
CompactSizeservicesサービスビット。64 ビット幅のビットフィールドで、CompactSize (https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer) でエンコードされる。
uint8_tnetworkIDネットワーク識別子。どのネットワークが指定されているかを示す 8 ビット値。
std::vector<uint8_t>addrネットワークアドレス。解釈は networkID に依存する。
uint16_tportネットワークポート。そのネットワークに関係しない場合、この値は 0 でなければならない（MUST）。

1 つのメッセージには最大 1,000件のアドレスを含められる。クライアントは、それを超える数のアドレスを含むメッセージを拒否すべきである（SHOULD）。

addrフィールドは可変長で、最大 512 バイト（4096 ビット）である。クライアントは、これより長いアドレスを含むメッセージを、ネットワーク ID に関わらず拒否すべきである（SHOULD）。

予約済みネットワーク ID の一覧は以下のとおりである。

ネットワーク ID列挙値アドレス長（バイト）説明
0x01IPV44IPv4 アドレス（グローバルにルーティングされるインターネット）
0x02IPV616IPv6 アドレス（グローバルにルーティングされるインターネット）
0x03TORV210Tor v2 隠しサービスアドレス（もはや使用されないTor v2 はもはや稼働しておらず、クライアントは Tor v2 アドレスをゴシップまたはリレーしてはならず（MUST NOT）、受信時には無視しなければならない（MUST））
0x04TORV332Tor v3 隠しサービスアドレス
0x05I2P32I2P オーバーレイネットワークアドレス
0x06CJDNS16Cjdns オーバーレイネットワークアドレス
0x07YGGDRASIL16Yggdrasil オーバーレイネットワークアドレス

クライアントは、既知のすべてのネットワークについて、現在それらの一部に接続していない場合であってもアドレスをゴシップすることが推奨される（RECOMMENDED）。これはマルチホームなノードの助けになり、観測者がそのノードがどのネットワークに接続しているかを判別することをより困難にしうる。

クライアントは、未知のネットワークからのアドレスをゴシップすべきではない（SHOULD NOT）。それらのアドレスを検証する手段がなく、無効なアドレスをゴシップするよう仕向けられうるためである。

新たなネットワーク ID 番号は、新しい BIP 文書で予約されなければならない（MUST）。

クライアントは、特定のネットワーク ID についてこの表に定められた長さと異なる長さを持つアドレスを含むメッセージを拒否すべきである（SHOULD）。それらは無意味であるためである。

IPV6アドレス空間の一部の範囲は、他のネットワークのアドレスを埋め込むために予約されている（例えば IPv4-in-IPv6 の範囲::ffff:0:0/96）。そのようなアドレスは、既に自身のネットワーク ID 配下で正規のエンコーディングを持っており、IPV6ネットワーク ID で送信してはならない（MUST NOT）。クライアントは、受信時にこれらの予約範囲に該当するIPV6アドレスを無視すべきである（SHOULD）。そうしなければ、同一のアドレスが 2 つのネットワーク ID のもとで受信された際、2 つの異なるピアとして扱われてしまうためである。

各ネットワークで用いられるアドレスエンコーディングについては付録を参照。

シグナリングのサポートと互換性

新しいメッセージタイプsendaddrv2を導入する。このメッセージを送信することは、そのノードがaddrメッセージの代わりにaddrv2メッセージを理解でき、それを受信することを好むことを示す。すなわち「addrv2 を送ってほしい」という意味である。このメッセージを送信するかどうかは、要求されていないアドレスメッセージの受信に関する選好を一切示唆しない。

sendaddrv2メッセージは、ピアからのversionメッセージへの応答としてのみ、かつverackメッセージを送信する前に送信しなければならない（MUST）。

sendaddrv2を発しない古いピアに対しては、新たに導入されたアドレス種別のアドレスを無視しつつ、従来どおり旧来のaddrメッセージを送信し続ける。

参照実装

参照実装は（未対応）で入手できる。

謝辞

  • ジョナス・シュネリ：常に 8 バイトを使う代わりに、多くの場合でメッセージをよりコンパクトにするため、servicesフィールドを CompactSize (https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer) へ変更。

  • Gregory Maxwell：拡張性に関する各種の提案

付録 A：Tor v2 アドレスエンコーディング（もはや使用されない）

新しいメッセージは、TORV2用に別個のネットワーク ID を導入する。

クライアントは、Tor 隠しサービスアドレスをこのネットワーク ID で、80 ビットの隠しサービス ID をアドレスフィールドに入れて送信しなければならない（MUST）。これは、OnionCat ラッピングの 6 バイトのプレフィックスを除いた、旧来のaddrメッセージにおける表現と同一である。

クライアントは、IPV6ネットワーク ID で届いた OnionCat（fd87:d87e:eb43::/48）アドレスを、受信時に無視すべきである（SHOULD）。

付録 B：Tor v3 アドレスエンコーディング

仕様Tor Rendezvous Specification - Version 3: Encoding onion addresses (https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt)によれば、次世代の.onionアドレスは以下のようにエンコードされる。

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

Tor v3 アドレスは、32 バイトの PUBKEY 部分をアドレスフィールドに入れてTORV3ネットワーク ID で送信しなければならない（MUST）。v3 アドレスの場合、VERSION は常に’\x03’であるため、これだけで onion アドレスを再構成するのに十分である。

付録 C：I2P アドレスエンコーディング

Tor と同様、I2P のネーミングも base32 エンコードされたアドレス形式を用いるI2P: Naming and address book (https://geti2p.net/en/docs/naming#base32)。

I2P は、完全な SHA-256 ハッシュを表すために 52 文字（256 ビット）を用い、その後に.b32.i2pが続く。

I2P アドレスは、デコードされた SHA-256 ハッシュをアドレスフィールドに入れてI2Pネットワーク ID で送信しなければならない（MUST）。

付録 D：Cjdns アドレスエンコーディング

Cjdns アドレスは、単にfc00::/8の範囲にある IPv6 アドレスであるCjdns whitepaper: Pulling It All Together (https://github.com/cjdelisle/cjdns/blob/6e46fa41f5647d6b414612d9d63626b0b952746b/doc/Whitepaper.md#pulling-it-all-together)。CJDNSネットワーク ID で送信しなければならない（MUST）。

付録 E：Yggdrasil アドレスエンコーディング

Yggdrasil アドレスは、単に0200::/7の範囲にある IPv6 アドレスであるYggdrasil FAQ (https://yggdrasil-network.github.io/faq.html#will-yggdrasil-conflict-with-my-network-routing)。YGGDRASILネットワーク ID で送信しなければならない（MUST）。

変更履歴

  • 2.1.0（2026-08-03）：
    • IPv4-in-IPv6 の範囲は IPV6 ネットワーク ID で送信してはならず（MUST NOT）、受信時には無視すべき（SHOULD）ことを明記。
  • 2.0.0（2025-10-01）：
    • Tor v2 がもはや稼働していない旨の注記を追加。
  • 1.0.0（2019-02-27）：
    • 初版

参考文献

関連エントリー

原典の外部ソース

https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki