VirtualAddrNetworkIPv6 man entry should say "[FC00::]/7"
IPv6 addresses have to have some colons somewhere.
Activity
changed milestone to %Tor: unspecified
The correct form is fc00::/7 without brackets. Brackets are used only with URI or to delineate ports as in https://[fc00::1]:443/ , and [fc00::1]:443 . Addresses must also be represented in lower case. I see numerous places in the manpage, and thus probably also in the code that need fixed to not use brackets and be lowercased.
Specification References...
IPv6 Address Text Representation
https://tools.ietf.org/html/rfc5952
IP Version 6 Addressing Architecture
https://tools.ietf.org/html/rfc4291
URI: Generic Syntax
https://tools.ietf.org/html/rfc3986
To make parsing easier for downstream consumers that may not know or utilize [good] parsing libraries (tor tool script writers, etc), you may want to override the 'should be followed' of rfc5952 and instead offer to write / print all output in the full 32 character form. If so I'd suggest making a new 'FullIPv6Representation" (FullIPv6Rep) config option for that. The ability to easily add a FullIPv6Rep may depend on if / where any syscall or output libraries are currently used to do the writing / printing, and their adaptability.
Replying to grarpamp:
Also, the correct form is fc00::/7 without brackets. Brackets are used with URI's to delineate ports as in https://[fc00::1]:443/ . Addresses must also be written in lower case. I see numerous places in the manpage, and thus probably also in the code that need fixed to not use brackets and be lowercased.
The code accepts any mix of lowercase and uppercase, I believe this to be a feature, not a bug. I'd be ok with making the man page and Tor output consistent, but I'm wary of breaking Control Port output parsers.
The code only accepts IPv6 addresses with brackets, and almost all contexts that accept an IPv6 address also accept a port. (This is one of the exceptions, there may be one or two more.) The current IPv6 parsing code also uses the brackets to distinguish between an IPv4 address and an IPv6 address. I think I'd prefer consistency over standards-compliance in this particular instance.
For tor purposes, I'd suggest to override the 'should be followed' of rfc5952 and instead write/print output only in the full 32 character form simply to make parsing easier for downstream consumers that may not utilize parsing libraries (tor tool script writers, etc). Or at least make a new 'FullIPv6Representation" (FullIPv6Rep) config option for it.
https://tools.ietf.org/html/rfc5952 https://tools.ietf.org/html/rfc4291 https://tools.ietf.org/html/rfc3986
This is a different issue, please open an enhancement request. Putting multiple requests in the same issue makes it likely that some get missed.
Somewhat related, relay fingerprints also need to be lowercased and without embedded spaces. I think there's a ticket on that too.
I couldn't find a Core Tor/Tor-specific ticket, do you have the number? You might have been thinking of the OnionOO query syntax.
This would be ok for output, but for input, we need to keep accepting both forms.
Please feel free to open another ticket if you can't find one.
If so I'd suggest making a new 'FullIPv6Representation" (FullIPv6Rep) This is a different issue, please open an enhancement request. As it is secondary yet potentially tied in, I'd like to table the FullIPv6Rep part here for now.
Somewhat related, relay fingerprints also need to be I couldn't find a Core Tor/Tor-specific ticket, do you have the number? Moved the fingerprint subject to this ticket... https://trac.torproject.org/projects/tor/ticket/12799
moved to tpo/core/tor#20153 (closed)
