NetInfo cells contain the fields Other OR's address [variable] and This OR's addresses [variable]. I was wondering what their usage is. In addition, its documented that the size is variable, but there's no length field that will allow to know the exact size of these fields. So how exactly their size is determined?
3. Cell Packet format ... The 'Command' field of a fixed-length cell holds one of the following values: ... 8 -- NETINFO (Time and address info) (See Sec 4.5) ... VERSIONS and NETINFO cells are used to set up connections in link protocols v2 and higher; in link protocol v3 and higher, CERTS, AUTH_CHALLENGE, and AUTHENTICATE may also be used. See section 4 below. 4. Negotiating and initializing connections ... When the renegotiation handshake is used, both parties immediately send a VERSIONS cell (4.1 below), and after negotiating a link protocol version (which will be 2), each send a NETINFO cell (4.5 below) to confirm their addresses and timestamps. No other intervening cell types are allowed. When the in-protocol handshake is used, the initiator sends a VERSIONS cell to indicate that it will not be renegotiating. The responder sends a VERSIONS cell, a CERTS cell (4.2 below) to give the initiator the certificates it needs to learn the responder's identity, an AUTH_CHALLENGE cell (4.3) that the initiator must include as part of its answer if it chooses to authenticate, and a NETINFO cell (4.5). As soon as it gets the CERTS cell, the initiator knows whether the responder is correctly authenticated. At this point the initiator behaves differently depending on whether it wants to authenticate or not. If it does not want to authenticate, it MUST send a NETINFO cell. If it does want to authenticate, it MUST send a CERTS cell, an AUTHENTICATE cell (4.4), and a NETINFO. When this handshake is in use, the first cell must be VERSIONS, VPADDING, or AUTHORIZE, and no other cell type is allowed to intervene besides those specified, except for VPADDING cells. 4.5. NETINFO cells 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 MAY use the timestamp value to help decide if their clocks are skewed. Initiators MAY use "other OR's address" to help learn which address their connections may be originating from, if they do not know it; and to learn whether the peer will treat the current connection as canonical. Implementations SHOULD NOT trust these values unconditionally, especially when they come from non-authorities, since the other party can lie about the time or IP addresses it sees. Initiators SHOULD use "this OR's address" to make sure that they have connected to another OR at its canonical address. (See 5.3.1 below.) ... 6.4. Remote hostname lookup ... Type (1 octet) Length (1 octet) Value (variable-width) TTL (4 octets) "Length" is the length of the Value field. "Type" is one of: 0x00 -- Hostname 0x04 -- IPv4 address 0x06 -- IPv6 address 0xF0 -- Error, transient 0xF1 -- Error, nontransient
So the address value has a header of fixed length that includes the value length, a common pattern in network protocols (e.g. SOCKS).
All this information was found with ctrl+f -> NETINFO. I believe we've linked the specification to you multiple times in answers now, you might like to take the time to read it thoroughly.