commit 7282e122886e9198e8a9fb368252e9e99dde6eb9 Author: rl1987 rl1987@sdf.lonestar.org Date: Thu Nov 29 12:19:33 2018 +0200
Reword address format definition in section 4.5
Let's refrain from mentioning section 6.4 in here, as the format is not exactly the same - not all address type field values from section 6.4 make sense in NETINFO cell and NETINFO cell does not have a TTL value at the end of each address. It's a little confusing to suggest that there is a reuse of wire format fragment between RELAY_RESOLVED and NETINFO cells. --- tor-spec.txt | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/tor-spec.txt b/tor-spec.txt index 97d5159..9203842 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -857,10 +857,19 @@ see tor-design.pdf. Number of addresses [1 byte] This OR's addresses [variable]
- The address format is a type/length/value sequence as given in - section 6.4 below, without the final TTL. The timestamp is a - big-endian unsigned integer number of seconds since the Unix epoch. - Implementations MUST ignore unexpected bytes at the end of the cell. + The address format is as follows: + Type [1 byte] + * 0x04 - IPv4 + * 0x06 - IPv6 + Length (size of Value field) [1 byte] + * 4 if Type is IPv4 + * 16 if Type is IPv6 + Value [Variable-width] + * Address value in network byte order. + + The timestamp is a big-endian unsigned integer number of seconds + since the Unix epoch. Implementations MUST ignore unexpected bytes + at the end of the cell.
Implementations MAY use the timestamp value to help decide if their clocks are skewed. Initiators MAY use "other OR's address" to help