Only say that valid, potentially routable addresses SHOULD be gossiped.

(It is up to the node implementation what addresses on each network are considered valid
and potentially routable.)

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-08-23 15:58:52 +01:00
parent fc6e752b05
commit 7dc6682326
2 changed files with 8 additions and 7 deletions

View File

@ -18,7 +18,7 @@ License: BSD-2-Clause
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/542">https://github.com/zcash/zips/issues/542</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/543">https://github.com/zcash/zips/pull/543</a>&gt;</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
<p>The term "network upgrade" in this document is to be interpreted as described in ZIP 200. <a id="id2" class="footnote_reference" href="#zip-0200">4</a></p>
<p>The terms "Testnet" and "Mainnet" are to be interpreted as described in section 3.11 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#protocol-networks">2</a>.</p>
<p>"P2P network" means the Zcash peer-to-peer network.</p>
@ -128,7 +128,7 @@ Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/543">https://githu
</table>
</blockquote>
<p>Network ID <code>0x03</code> is intentionally not assigned. In BIP 155 <a id="id8" class="footnote_reference" href="#bip-0155">3</a> it was assigned to Tor v2 onion addresses, but those addresses are no longer supported by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.</p>
<p>Clients SHOULD 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.</p>
<p>Clients SHOULD gossip valid, potentially routable 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.</p>
<p>Clients MUST NOT gossip addresses from unknown networks, because they have no means to validate those addresses and so can be tricked to gossip invalid addresses.</p>
<p>Clients MUST reject messages that contain addresses that have a different length than specified in this table for a specific network ID, as these are meaningless.</p>
<section id="network-address-encodings"><h3><span class="section-heading">Network address encodings</span><span class="section-anchor"> <a rel="bookmark" href="#network-address-encodings"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>

View File

@ -16,8 +16,8 @@
Terminology
===========
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY"
in this document are to be interpreted as described in RFC 2119. [#RFC2119]_
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this
document are to be interpreted as described in RFC 2119. [#RFC2119]_
The term "network upgrade" in this document is to be interpreted as described in
ZIP 200. [#zip-0200]_
@ -111,9 +111,10 @@ Network ID ``0x03`` is intentionally not assigned. In BIP 155 [#bip-0155]_ it wa
assigned to Tor v2 onion addresses, but those addresses are no longer supported
by the latest Tor client code, and MUST NOT be used once this ZIP is deployed.
Clients SHOULD 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 gossip valid, potentially routable 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 MUST NOT gossip addresses from unknown networks, because they have no means
to validate those addresses and so can be tricked to gossip invalid addresses.