diff options
Diffstat (limited to 'tor-spec.txt')
| -rw-r--r-- | tor-spec.txt | 48 |
1 files changed, 34 insertions, 14 deletions
diff --git a/tor-spec.txt b/tor-spec.txt index 683900e..b2b26eb 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -852,15 +852,27 @@ see tor-design.pdf. If version 2 or higher is negotiated, each party sends the other a NETINFO cell. The cell's payload is: - Timestamp [4 bytes] - Other OR's address [variable] - 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. + TIME (Timestamp) [4 bytes] + OTHERADDR (Other OR's address) [variable] + ATYPE (Address type) [1 byte] + ALEN (Adress length) [1 byte] + AVAL (Address value in NBO) [ALEN bytes] + NMYADDR (Number of this OR's addresses) [1 byte] + NMYADDR times: + ATYPE (Address type) [1 byte] + ALEN (Adress length) [1 byte] + AVAL (Address value in NBO)) [ALEN bytes] + + Recognized address types (ATYPE) are: + [04] IPv4. + [06] IPv6. + + ALEN MUST be 4 when ATYPE is 0x04 (IPv4) and 16 when ATYPE is 0x06 + (IPv6). + + 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 @@ -1935,19 +1947,27 @@ see tor-design.pdf. it should warn its operator that the relay is obsolete. - When a relay lacks a protocol listed in required-relay-protocols, it - must not attempt to join the network. + should warn its operator as above. If the consensus is newer than the + date when the software was released or scheduled for release, it must + not attempt to join the network. - When a client lacks a protocol listed in recommended-client-protocols, it should warn the user that the client is obsolete. - - When a client lacks a protocol listed in required-client-protocols, it - must not connect to the network. This implements a "safe forward - shutdown" mechanism for zombie clients. + - When a client lacks a protocol listed in required-client-protocols, + it should warn the user as above. If the consensus is newer than the + date when the software was released, it must not connect to the + network. This implements a "safe forward shutdown" mechanism for + zombie clients. - If a client or relay has a cached consensus telling it that a given protocol is required, and it does not implement that protocol, it SHOULD NOT try to fetch a newer consensus. + Software release dates SHOULD be automatically updated as part of the + release process, to prevent forgetting to move them forward. Software + release dates MAY be manually adjusted by maintainers if necessary. + Starting in version 0.2.9.4-alpha, the initial required protocols for clients that we will Recommend and Require are: @@ -1979,7 +1999,7 @@ see tor-design.pdf. 9.2. "LinkAuth" LinkAuth protocols correspond to varieties of Authenticate cells used for - the v3+ link protocools. + the v3+ link protocols. Current versions are: |