[tor-dev] Please consider allowing /48 for VirtualAddrNetworkIPv6

grarpamp grarpamp at gmail.com
Sat Sep 17 08:45:00 UTC 2016


On Fri, Sep 16, 2016 at 6:10 PM, Alex Elsayed <eternaleye at gmail.com> wrote:
>> (Yes, there is a typo in the last IPv6 address as well.
>> https://trac.torproject.org/projects/tor/ticket/20153 )

Yes Tor is making some quite bad text representation issues
so I added summary of them to this ticket.

> - [FC00]/8 is _reserved by the IANA_, and beyond that, CJDNS is already
> squatting on it. :/

As all their independant users are not really one 'AS number' like
entity where the concept of 'local' policy would then apply to all, CJDNS
does present some problems in this area. Possibly with interoperating
with other IPv6 based overlay networks and adapters / tunnels. I hope
they're aware of them. Unfortunately to fix I think they'd have to rearchitect,
or at least renumber to squat elsewhere... both being rather unpalatable
from their point of view. Specifically, if I recall, they're abusing the 'L' bit
in the RFC, squatting the undefined 0. I don't think so but would have to
double check if they're also stomping the 1. Obviously generating into
a proper L=1 /48 is not practical. As with the .onion and .i2p DNS
reservations, I'd highly suggest CJDNS apply to IANA for a special
/whatever they could then generate into.


Yes in general networks shouldn't ride on top of space others are
legitimately using per RFC, such as the ULA space. Even riding
on some unallocated unicast space outside 2000::/3 that IANA is
unlikely to ever allocate to the global IPv6 routing table of host
networks would be preferred over that. That is, if you don't apply
for a special purpose allocation.

http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
https://tools.ietf.org/html/rfc4193


More information about the tor-dev mailing list