mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 7: allow multiple address descriptors. (Take II) (#60)

Browse Source 
This lets us have both IPv4 and IPv6 (and Tor etc in future) address,
while still preserving the ability to add other fields to the message
in future.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2016-12-20 14:23:11 +10:30 committed by GitHub
parent 69b8767017
commit 6e99d24619
1 changed files with 38 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
07-routing-gossip.md
View File

@ -144,30 +144,51 @@ nodes for which a channel is not already known are ignored.
2. data:
* [64:signature]
* [4:timestamp]
* [16:ipv6]
* [2:port]
* [33:node-id]
* [3:rgb-color]
* [32:alias]
* [2:len]
* [len:features]
* [2:flen]
* [flen:features]
* [2:addrlen]
* [addrlen:addresses]
The `timestamp` allows ordering in the case of multiple announcements;
the `ipv6` and `port` allow the node to announce its willingness to
accept incoming network connections, the `rgb-color` and `alias` allow
the `rgb-color` and `alias` allow
intelligence services to give their nodes cool monikers like IRATEMONK
and WISTFULTOLL and use the color black.
`addresses` allows the node to announce its willingness to accept
incoming network connections: it contains series of `address
descriptor`s for connecting to the node. The first byte describes the
address type, followed by the appropriate number of bytes for that type.
The following `address descriptor` types are defined:
1. `0`: padding. data = none (length 0).
1. `1`: IPv4. data = `[4:ipv4-addr][2:port]` (length 6)
2. `2`: IPv6. data = `[16:ipv6-addr][2:port]` (length 18)
### Requirements
The creating node MUST set `timestamp` to be greater than any previous
`node_announcement` it has created. It MAY base it on a UNIX
timestamp. It MUST set the `ipv6` and `port` fields to all zeroes, or
a non-zero `port` and `ipv6` set to a valid IPv6 address or an IPv4-Mapped IPv6 Address format as defined in [RFC 4291 section 2.5.5.2](https://tools.ietf.org/html/rfc4291#section-2.5.5.2). It MUST set `signature` to the signature of
timestamp. It MUST set `signature` to the signature of
the double-SHA256 of the entire remaining packet after `signature` using the
key given by `node-id`. It MAY set `alias` and `rgb-color` to customize their node's appearance in maps and graphs, where the first byte of `rgb` is the red value, the second byte is the green value and the last byte is the blue value. It MUST set `alias` to a valid UTF-8 string, with any `alias` bytes following equal to zero.
The creating node SHOULD set `len` to the minimum length required to
The creating node SHOULD fill `addresses` with an address descriptor
for each public network address which expects incoming connections,
and MUST set `addrlen` to the number of bytes in `addresses`.
Non-zero typed address descriptors MUST be placed in ascending order;
any number of zero-typed address descriptors MAY be placed anywhere,
but SHOULD only be used for aligning fields following `addresses`.
The creating node MUST NOT create a type 1 or type 2 address
descriptor with `port` equal to zero, and SHOULD ensure `ipv4-addr`
and `ipv6-addr` are routable addresses. The creating node MUST NOT include
more than one `address descriptor` of the same type.
The creating node SHOULD set `flen` to the minimum length required to
hold the `features` bits it sets.
The receiving node SHOULD fail the connection if `node-id` is not a valid
@ -178,7 +199,10 @@ valid signature using `node-id` of the double-SHA256 of the entire
message following the `signature` field (including unknown fields
following `alias`), and MUST NOT further process the message.
The receiving node SHOULD ignore `ipv6` if `port` is zero.
The receiving node SHOULD ignore the first `address descriptor` which
does not match the types defined above. The receiving node SHOULD
fail the connection if `addrlen` is insufficient to hold the address
descriptors of the known types.
The receiving node SHOULD ignore the message if `node-id` is not
previously known from a `channel_announcement` message, or if
@ -201,14 +225,10 @@ optional) ones will have odd feature bits, incompatible ones will have
even feature bits. These will be propagated by nodes even if they
can't use the announcements themselves.
RFC 4291 section 2.5.5.2 described IPv4 addresses like so:
```
| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|FFFF| IPv4 address |
+--------------------------------------+----+---------------------+
```
New address types can be added in future; as address descriptors have
to be ordered in ascending order so they will be safely ignored.
Future fields beyond `addresses` can still be added, optionally with
padding within `addresses` if they require certain alignment.
## The `channel_update` message
@ -320,8 +340,6 @@ of local channels.
## References
- [RFC 4291](https://tools.ietf.org/html/rfc4291)
![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY")
<br>
This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).