refactor: use rfc6890 special-purpose addresses (#505)

RFC/0003-routing-records.md

@@ -126,10 +126,10 @@ epoch time as the `seq` value, however they MUST NOT attempt to interpret a
     seq: 1570215229,
     addresses: [
       {
-        multiaddr: "/ip4/1.2.3.4/tcp/42/p2p/QmAlice",
+        multiaddr: "/ip4/192.0.2.0/tcp/42/p2p/QmAlice",
       },
       {
-        multiaddr: "/ip4/10.0.1.2/tcp/42/p2p/QmAlice",
+        multiaddr: "/ip4/198.51.100.0/tcp/42/p2p/QmAlice",
       }
     ]
   }
@@ -208,7 +208,6 @@ And possibly:
 - `IsCertified(peer_id, multiaddr) -> Boolean`
   - has a particular address been self-certified by the given peer?
 
-
 We'll also need a method that constructs a new `RoutingState` containing our
 listen addresses and wraps it in a signed envelope. This may belong on the Host
 instead of the peer store, since it needs access to the private signing key.
@@ -273,14 +272,11 @@ filter that could be used to test whether a peer supports a given protocol
 before interacting with them directly. This could be added as a new field in the
 `RoutingState` message.
 
-
-
 [identify-spec]: ../identify/README.md
 [peer-id-spec]: ../peer-ids/peer-ids.md
 [mdns-spec]: ../discovery/mdns.md
 [rendezvous-spec]: ../rendezvous/README.md
 [pex-proposal]: https://github.com/libp2p/notes/issues/7
-[autonat]: https://github.com/libp2p/specs/issues/180
 [envelope-rfc]: ./0002-signed-envelopes.md
 [eip-778]: https://eips.ethereum.org/EIPS/eip-778
 [dht-spec]: https://github.com/libp2p/specs/blob/master/kad-dht/README.md

addressing/README.md

@@ -1,17 +1,16 @@
 # Addressing in libp2p  <!-- omit in toc -->
+>
 > How network addresses are encoded and used in libp2p
 
 | Lifecycle Stage | Maturity       | Status | Latest Revision |
 |-----------------|----------------|--------|-----------------|
 | 3A              | Recommendation | Active | r0, 2021-07-22  |
 
-
 Authors: [@yusefnapora]
 
 Interest Group: [@mxinden, @Stebalien, @raulk, @marten-seemann, @vyzo]
 
 [@yusefnapora]: https://github.com/yusefnapora
-[@mxinden]: https://github.com/mxinden/
 
 See the [lifecycle document][lifecycle-spec] for context about the maturity level
 and spec status.
@@ -45,7 +44,7 @@ derived from public keys as described in the [peer id spec][peer-id-spec].
 
 On a particular network, at a specific point in time, a peer may have one or
 more locations, which can be represented using addresses. For example, I may be
-reachable via the global IPv4 address of 7.7.7.7 on TCP port 1234.
+reachable via the global IPv4 address of 198.51.100 on TCP port 1234.
 
 In a system that only supported TCP/IP or UDP over IP, we could easily write our
 addresses with the familiar `<ip>:<port>` notation and store them as tuples of
@@ -77,16 +76,16 @@ multiaddr](#the-p2p-multiaddr).
 A multiaddr is a sequence of instructions that can be traversed to some
 destination.
 
-For example, the `/ip4/7.7.7.7/tcp/1234` multiaddr starts with `ip4`, which is
+For example, the `/ip4/198.51.100/tcp/1234` multiaddr starts with `ip4`, which is
 the lowest-level protocol that requires an address. The `tcp` protocol runs on
 top of `ip4`, so it comes next.
 
-The multiaddr above consists of two components, the `/ip4/7.7.7.7` component,
+The multiaddr above consists of two components, the `/ip4/198.51.100` component,
 and the `/tcp/1234` component. It's not possible to split either one further;
 `/ip4` alone is an invalid multiaddr, because the `ip4` protocol was defined to
 require a 32 bit address. Similarly, `tcp` requires a 16 bit port number.
 
-Although we referred to `/ip4/7.7.7.7` and `/tcp/1234` as "components" of a
+Although we referred to `/ip4/198.51.100` and `/tcp/1234` as "components" of a
 larger TCP/IP address, each is actually a valid multiaddr according to the
 multiaddr spec. However, not every **syntactically valid multiaddr is a
 functional description of a process in the network**. As we've seen, even a
@@ -121,28 +120,28 @@ TCP/IP streams, or TCP segments themselves encapsulated within IP datagrams.
 The multiaddr format was designed so that addresses encapsulate each other in
 the same manner as the protocols that they describe. The result is an address
 that begins with the "outermost" layer of the network stack and works
-progressively "inward". For example, in the address `/ip4/7.7.7.7/tcp/80/ws`,
+progressively "inward". For example, in the address `/ip4/198.51.100/tcp/80/ws`,
 the outermost protocol is IPv4, which encapsulates TCP streams, which in turn
 encapsulate WebSockets.
 
 All multiaddr implementations provide a way to _encapsulate_ two multiaddrs into
-a composite. For example, `/ip4/7.7.7.7` can encapsulate `/tcp/42` to become
-`/ip4/7.7.7.7/tcp/42`.
+a composite. For example, `/ip4/198.51.100` can encapsulate `/tcp/42` to become
+`/ip4/198.51.100/tcp/42`.
 
 #### Decapsulation
 
 Decapsulation takes a composite multiaddr and removes an "inner" multiaddr from
 it, returning the result.
 
-For example, if we start with `/ip4/7.7.7.7/tcp/1234/ws` and decapsulate `/ws`,
-the result is `/ip4/7.7.7.7/tcp/1234`.
+For example, if we start with `/ip4/198.51.100/tcp/1234/ws` and decapsulate `/ws`,
+the result is `/ip4/198.51.100/tcp/1234`.
 
 It's important to note that decapsulation returns the original multiaddr up to
 the last occurrence of the decapsulated multiaddr. This may remove more than
 just the decapsulated component itself if there are more protocols encapsulated
 within it. Using our example above, decapsulating either `/tcp/1234/ws` _or_
-`/tcp/1234` from `/ip4/7.7.7.7/tcp/1234/ws` will result in `/ip4/7.7.7.7`. This is
-unsurprising if you consider the utility of the `/ip4/7.7.7.7/ws` address that
+`/tcp/1234` from `/ip4/198.51.100/tcp/1234/ws` will result in `/ip4/198.51.100`. This is
+unsurprising if you consider the utility of the `/ip4/198.51.100/ws` address that
 would result from simply removing the `tcp` component.
 
 ### The p2p multiaddr
@@ -167,7 +166,7 @@ For example, the above `p2p` address can be combined with the transport address
 on which the node is listening:
 
 ```
-/ip4/7.7.7.7/tcp/1234/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N
+/ip4/198.51.100/tcp/1234/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N
 ```
 
 This combination of transport address plus `p2p` address is the format in which
@@ -182,7 +181,6 @@ printed as `/ipfs/<peer-id>` instead of `/p2p/<peer-id>` in its string represent
 depending on the implementation in use. Both names resolve to the same protocol code,
 and they are equivalent in the binary form.
 
-
 ## Transport multiaddrs
 
 Because multiaddr is an open and extensible format, it's not possible to
@@ -201,7 +199,7 @@ Most libp2p transports use the IP protocol as a foundational layer, and as a
 result, most transport multiaddrs will begin with a component that represents an
 IPv4 or IPv6 address.
 
-This may be an actual address, such as `/ip4/7.7.7.7` or
+This may be an actual address, such as `/ip4/198.51.100` or
 `/ip6/fe80::883:a581:fff1:833`, or it could be something that resolves to an IP
 address, like a domain name.
 
@@ -216,7 +214,6 @@ resolvable or "name-based" protocols:
 | `dns6`    | Resolves DNS AAAA records into IPv6 addresses.                     |
 | `dnsaddr` | Resolves multiaddrs from a special TXT record.                     |
 
-
 When the `/dns` protocol is used, the lookup may result in both IPv4 and IPv6
 addresses, in which case IPv6 will be preferred. To explicitly resolve to IPv4
 or IPv6 addresses, use the `/dns4` or `/dns6` protocols, respectively.
@@ -227,8 +224,8 @@ runtime will determine what IP version is used.
 
 When a name-based multiaddr encapsulates another multiaddr, only the name-based
 component is affected by the lookup process. For example, if `example.com`
-resolves to `1.2.3.4`, libp2p will resolve the address
-`/dns4/example.com/tcp/42` to `/ip4/1.2.3.4/tcp/42`.
+resolves to `192.0.2.0`, libp2p will resolve the address
+`/dns4/example.com/tcp/42` to `/ip4/192.0.2.0/tcp/42`.
 
 #### dnsaddr Links
 
@@ -244,6 +241,7 @@ For example, resolving `/dnsaddr/libp2p.io` will perform a `TXT` lookup for
 
 For example, asking the DNS server for the TXT records of one of the bootstrap
 nodes, `ams-2.bootstrap.libp2p.io`, returns the following records:
+
 ```
 > dig +short _dnsaddr.ams-2.bootstrap.libp2p.io txt
 "dnsaddr=/dns4/ams-2.bootstrap.libp2p.io/tcp/443/wss/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb"
@@ -291,7 +289,6 @@ where `<ip-multiaddr>` is a multiaddr that resolves to an IP address, as
 described in the [IP and Name Resolution section](#ip-and-name-resolution).
 The `<udp-port>` argument must be a 16-bit unsigned integer in network byte order.
 
-
 ### `p2p-circuit` Relay Addresses
 
 The libp2p [circuit relay protocol][relay-spec] allows a libp2p peer A to
@@ -319,15 +316,14 @@ destination peer.
 A full example would be:
 
 ```
-/ip4/127.0.0.1/tcp/5002/p2p/QmdPU7PfRyKehdrP5A3WqmjyD6bhVpU1mLGKppa2FjGDjZ/p2p-circuit/p2p/QmVT6GYwjeeAF5TR485Yc58S3xRF5EFsZ5YAF4VcP3URHt
+/ip4/192.0.2.0/tcp/5002/p2p/QmdPU7PfRyKehdrP5A3WqmjyD6bhVpU1mLGKppa2FjGDjZ/p2p-circuit/p2p/QmVT6GYwjeeAF5TR485Yc58S3xRF5EFsZ5YAF4VcP3URHt
 ```
 
 Here, the destination peer has the peer id
 `QmVT6GYwjeeAF5TR485Yc58S3xRF5EFsZ5YAF4VcP3URHt` and is reachable through a
 relay node with peer id `QmdPU7PfRyKehdrP5A3WqmjyD6bhVpU1mLGKppa2FjGDjZ` running
 on TCP port 5002 of the IPv4 loopback interface.
 
-
 [peer-id-spec]: ../peer-ids/peer-ids.md
 [identify-spec]: ../identify/README.md
 [multiaddr-repo]: https://github.com/multiformats/multiaddr

discovery/mdns.md

@@ -24,26 +24,25 @@ and spec status.
 ## Table of Contents
 
 - [Multicast DNS (mDNS)](#multicast-dns-mdns)
-    - [Table of Contents](#table-of-contents)
-    - [Overview](#overview)
-    - [Definitions](#definitions)
-    - [Peer Discovery](#peer-discovery)
-        - [Request](#request)
-        - [Response](#response)
-    - [DNS Service Discovery](#dns-service-discovery)
-        - [Meta Query](#meta-query)
-        - [Find All Response](#find-all-response)
-        - [Gotchas](#gotchas)
-    - [Issues](#issues)
-    - [References](#references)
-    - [Worked Examples](#worked-examples)
-        - [Meta Query](#meta-query-1)
-            - [Question](#question)
-            - [Answer](#answer)
-        - [Find All Peers](#find-all-peers)
-            - [Question](#question-1)
-            - [Answer](#answer-1)
-            - [Additional Records](#additional-records)
+  - [Table of Contents](#table-of-contents)
+  - [Overview](#overview)
+  - [Definitions](#definitions)
+  - [Peer Discovery](#peer-discovery)
+    - [Request](#request)
+    - [Response](#response)
+  - [DNS Service Discovery](#dns-service-discovery)
+    - [Meta Query](#meta-query)
+    - [Find All Response](#find-all-response)
+    - [Gotchas](#gotchas)
+  - [Issues](#issues)
+  - [References](#references)
+    - [Meta Query](#meta-query-1)
+      - [Question](#question)
+      - [Answer](#answer)
+    - [Find All Peers](#find-all-peers)
+      - [Question](#question-1)
+      - [Answer](#answer-1)
+      - [Additional Records](#additional-records)
 
 ## Overview
 
@@ -165,5 +164,5 @@ _p2p._udp.local IN PTR `<peer-name>`._p2p._udp.local
 
 #### Additional Records
 
-- `<peer-name>`._p2p._udp.local IN TXT dnsaddr=/ip6/fe80::7573:b0a8:46b0:bfea/tcp/4001/p2p/`id`
-- `<peer-name>`._p2p._udp.local IN TXT dnsaddr=/ip4/192.168.178.21/tcp/4001/p2p/`id`
+- `<peer-name>`._p2p._udp.local IN TXT dnsaddr=/ip6/2001:DB8::7573:b0a8:46b0:bfea/tcp/4001/p2p/`id`
+- `<peer-name>`._p2p._udp.local IN TXT dnsaddr=/ip4/192.0.2.0/tcp/4001/p2p/`id`

relay/circuit-v1.md

@@ -97,7 +97,7 @@ A `/p2p-circuit` circuit address, is formatted as following:
 Examples:
 
 - `/p2p-circuit/p2p/QmVT6GYwjeeAF5TR485Yc58S3xRF5EFsZ5YAF4VcP3URHt` - Arbitrary relay node that can relay to `QmVT6GYwjeeAF5TR485Yc58S3xRF5EFsZ5YAF4VcP3URHt` (target)
-- `/ip4/127.0.0.1/tcp/5002/p2p/QmdPU7PfRyKehdrP5A3WqmjyD6bhVpU1mLGKppa2FjGDjZ/p2p-circuit/p2p/QmVT6GYwjeeAF5TR485Yc58S3xRF5EFsZ5YAF4VcP3URHt` - Specific relay node to relay to `QmVT6GYwjeeAF5TR485Yc58S3xRF5EFsZ5YAF4VcP3URHt` (target)
+- `/ip4/192.0.2.0/tcp/5002/p2p/QmdPU7PfRyKehdrP5A3WqmjyD6bhVpU1mLGKppa2FjGDjZ/p2p-circuit/p2p/QmVT6GYwjeeAF5TR485Yc58S3xRF5EFsZ5YAF4VcP3URHt` - Specific relay node to relay to `QmVT6GYwjeeAF5TR485Yc58S3xRF5EFsZ5YAF4VcP3URHt` (target)
 
 This opens the room for multiple hop relay, where the second relay is encapsulated in the first relay multiaddr, such that one relay relays to the next relay, in a daisy-chain fashion. Example: