mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-01-18 13:22:35 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 1: adds remote address to optional init_tlvs

Browse Source 
This adds the option to report an remote IP address back to a connecting
peer using the `init` message. A node can decide to use that information
to discover a potential update to its public IPv4 address (NAT) and use
that for a `node_announcement` update message containing the new address.

The proposal includes reporting the IPv4 and IPv6 address,
however in IPv6 there are likely no NAT issues. TOR is skipped for
obvious reasons.

Certain approaches to check and use this information are thinkable:
 - Wait for multiple peers or a certain fraction to report the
   same new address.
 - Check some random node known via gossip to also report the new
   address.
 - Verify this information by making a test connection to itself.
This commit is contained in:
Michael Schmoock 2021-09-27 13:59:10 +02:00
parent ea37941537
commit efe9d2d151
1 changed files with 9 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
01-messaging.md
View File

@ -265,8 +265,12 @@ The `features` field MUST be padded to bytes with 0s.
2. data:
* [`...*chain_hash`:`chains`]
1. type: 3 (`remote_addr`)
2. data:
* `address descriptor` (1 byte type and data, see BOLT 7)
The optional `networks` indicates the chains the node is interested in.
The optional `remote_addr` can be used to circumvent NAT issues.
#### Requirements
@ -277,6 +281,10 @@ The sending node:
- SHOULD NOT set features greater than 13 in `globalfeatures`.
- SHOULD use the minimum length required to represent the `features` field.
- SHOULD set `networks` to all chains it will gossip or open channels for.
- SHOULD set `remote_addr` to reflect the remote IP address (and port) of an
incoming connection, if the node is the receiver and the connection was done
via IP.
- SHOULD NOT set private addresses as `remote_addr`.
The receiving node:
- MUST wait to receive `init` before sending any other messages.
@ -290,6 +298,7 @@ The receiving node:
- MAY close the connection.
- if the feature vector does not set all known, transitive dependencies:
- MUST close the connection.
- MAY use the `remote_addr` to update its `node_annoucement`
#### Rationale