On Fri, Sep 16, 2016 at 6:10 PM, Alex Elsayed eternaleye@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... https://tools.ietf.org/html/rfc4193