[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] Reword address format definition in section 4.5
commit 7282e122886e9198e8a9fb368252e9e99dde6eb9
Author: rl1987 <rl1987@xxxxxxxxxxxxxxxx>
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
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits