Allow clients and relays to send dual-stack and IPv6-only EXTEND2 cells.
Parse dual-stack and IPv6-only EXTEND2 cells on relays.
Relays do not make connections or extend circuits via IPv6: that's the
next step.
Closes ticket 33901.
The parts for handling cell formats should be in src/core/or.
The parts for handling onionskin queues should be in src/core/or.
Only the crypto wrapper belongs in src/core/crypto.
* ADD new /src/common/crypto_rand.[ch] module.
* ADD new /src/common/crypto_util.[ch] module (contains the memwipe()
function, since all crypto_* modules need this).
* FIXES part of #24658: https://bugs.torproject.org/24658
By now, support in the network is widespread and it's time to require
more modern crypto on all Tor instances, whether they're clients or
servers. By doing this early in 0.2.6, we can be sure that at some point
all clients will have reasonable support.
As elsewhere, it makes sense when adding or extending a cell type to
actually make the code to parse it into a separate tested function.
This commit doesn't actually make anything use these new functions;
that's for a later commit.
This makes it so we can handle getting an IPv6 in the 3 different
formats we specified it for in RESOLVED cells,
END_STREAM_REASON_EXITPOLICY cells, and CONNECTED cells.
We don't cache IPv6 addresses yet, since proposal 205 isn't
implemented.
There's a refactored function for parsing connected cells; it has unit
tests.