IPv6 support inside tunnels about lokinet HOT 16 CLOSED

from lokinet.

While I definitely want IPv6 support for exits, I'm unsure how to feel about IPv6-only. Some of things are still IPv4-only :\
You probably want to give globally routable IPv6 address (based on client' public key) to interface.
Should we support NPTv6 use case too? Unsure if having constant ULA NPTv6 address or changing-when-exit-changes globally routable IPv6 would be better..

1. there aren't any good deprecated or unused private ipv6 ranges left that I can use that I know of.

could use some /48 or /64 subnet of fd00::/8 but yeah that's sorta ugly

2. ipv4 only exits would be NAT'd HELL on earth.

end2end connectivity and possibility to host services would be sorta cool but unsure if it's critical use case

3. would provide a clear separation between hidden service and exit traffic

imo could be separated by using packet destination address; we'd still use source address of zeros, and leave OS to handle NAT. less clear but not something impossibly confusing.

from lokinet.

from lokinet.

based on client' public key

nvm that's really bad idea for fingerprintability (and also exits would need to keep state of peers either way so not much would be gained with that).

from lokinet.

that means we would probably use SIIT with NAT if we do any ipv4 exit traffic.

SIIT sounds like more work to do, and also has some edges like MTU being different for IPv4 and IPv6 (how the hell would his handled for tun interfaces? multiple of them?)

from lokinet.

from lokinet.

for MTU we'll probably pick the smallest initially.

I don't like that.

it could be negotiated with the exit.

more work to do.

Is there anything really wrong with using same kind of IPv4 packets for exit traffic, other than "stuffing everything to IPv6 for that looks cleaner to me"?

from lokinet.

from lokinet.

https://tools.ietf.org/html/rfc7915 (SIIT) seems like quite hell of work to do (and I don't want llarp to do this kind of work as it'll be possible bug source and even implemented properly still has some very undesirable properties like requiring lower MTU, handling of fragmentation), so I'd rather not have IPv4 support initially than have it implemented this way.

from lokinet.

from lokinet.

Well, my current proposal for IPv4 exit traffic would be packets with client' src address set to 0.0.0.0 and dst address to globally routable (not in 0.0.0.0/8) IPv4 address.
Older clients have both src and dst addresses non-0.
Newer clients have both src and dst addresses 0.
Other IPv4 addresses from 0.0.0.0/8 range could be used for future extensions.

from lokinet.

Older clients have both src and dst addresses non-0.
Newer clients have both src and dst addresses 0.

clarification: for hidden service to hidden service traffic

for clearnet->client, src would be globaly routable IPv4 address, dst would be 0.0.0.0

from lokinet.

internally everything is represented as ipv6 anyways, including ipv4 addresses as hybrid dualstack addresses (::ffff:8.8.8.8)

no blockers on my end, i already require some inet6 driver installed on the host system just to read out RCs

• tcpip6.sys in v5
• integrated into plain old tcpip.sys elsewhere

from lokinet.

i have implemented part of this in my ipv6-tun branch

from lokinet.

priv

it's possible that https://github.com/onioncat/onioncat/blob/master/glob_id.txt are not used at all.
At least i cannot connect to any of the ipv6 tor/i2p that are known.

from lokinet.

closing since we have ipv6 code now

from lokinet.