ビットコイン・インスティテュート
ビットコイン・インスティテュート
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メッセージを送信し続ける。

参照実装

参照実装の入手先は、まだ用意されていない（to be done）。

謝辞

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

  • グレゴリー・マクスウェル：拡張性に関する各種の提案

付録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