BOLT 1: adds remote address to optional init_tlvs

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.

01-messaging.md

@@ -214,6 +214,7 @@ receiver to parse individual elements from `value`.
 Various fundamental types are referred to in the message specifications:
 
 * `byte`: an 8-bit byte
+* `u8`: a 1 byte unsigned integer
 * `u16`: a 2 byte unsigned integer
 * `u32`: a 4 byte unsigned integer
 * `u64`: an 8 byte unsigned integer
@@ -259,6 +260,17 @@ The `features` field MUST be padded to bytes with 0s.
  2. data:
  * [`...*chain_hash`:`chains`]
 
+ 1. type: 2 (`remote_addr`)
+ 2. data:
+ * [`u8`:`addr_type`]
+ * `remote_addr_data`: `remote_addr`
+ 1. addr_type: 1 (ipv4)
+ 2. data:
+ * `[4:ipv4_addr][2:port]` (length 6)
+ 1. addr_type: 2 (ipv6)
+ 2. data:
+ * `[16:ipv6_addr][2:port]` (length 18)
+
 
 The optional `networks` indicates the chains the node is interested in.
 
@@ -271,6 +283,8 @@ 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 IP address of an incoming
+ connection, if the node is the receiver and the connection was done via IP.
 
 The receiving node:
  - MUST wait to receive `init` before sending any other messages.
@@ -284,6 +298,9 @@ The receiving node:
  - MAY fail the connection.
  - if the feature vector does not set all known, transitive dependencies:
  - MUST fail the connection.
+ - MAY use the `remote_addr` to send an updated `node_annoucement` message
+ when it verified the correctness of the address (i.e. by cross checking
+ with other peers or trying to connect to itself).
 
 #### Rationale