Opened 3 years ago

Last modified 2 years ago

#20153 new defect

VirtualAddrNetworkIPv6 man entry should say "[FC00::]/7"

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: easy, tor-doc, manpage, standards-argument
Cc: Actual Points:
Parent ID: Points: 0.1
Reviewer: Sponsor:

Description

IPv6 addresses have to have some colons somewhere.

Child Tickets

Change History (9)

comment:1 Changed 3 years ago by grarpamp

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.

Last edited 3 years ago by grarpamp (previous) (diff)

comment:2 Changed 3 years ago by nickm

Before somebody goes around removing all the brackets, they should make sure that Tor actually accepts these things without the brackets.

Tor also uses brackets to separate IPv6 addresses from ports, as in "reject [fc00::1]:80"

comment:3 in reply to:  2 Changed 3 years ago by grarpamp

make sure that Tor actually accepts these things without the brackets.

Of course, as above 'in the code'.

"reject [fc00::1]:80"

It is correct to use brackets to delineate ports when ports are present.

comment:4 in reply to:  1 ; Changed 3 years ago by teor

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.

comment:5 in reply to:  4 Changed 3 years ago by grarpamp

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

Last edited 3 years ago by grarpamp (previous) (diff)

comment:6 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:7 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:8 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:9 Changed 2 years ago by nickm

Keywords: tor-doc manpage standards-argument added; doc removed
Note: See TracTickets for help on using tickets.