Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

IPv6 support inside tunnels #28

Closed
cathugger opened this issue Oct 12, 2018 · 16 comments
Closed

IPv6 support inside tunnels #28

cathugger opened this issue Oct 12, 2018 · 16 comments
Labels
enhancement New feature or request

Comments

@cathugger
Copy link
Contributor

Currently we only support IPv4 inside tunnels.
IPv4 should stay.
IPv6 to IPv6 communication could be added without too much trouble.
But IPv6 to IPv4 (and back) translation could be very tricky.
How we could approach this? How would DNS resolving relate to this?
Or we should not add IPv6 support at all?
IPv6 would work better for mapping large amount of peers.
@majestrate
Copy link
Contributor

majestrate commented Oct 12, 2018 via email

@cathugger
Copy link
Contributor Author

cathugger commented Oct 12, 2018 •
edited
Loading

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

  1. 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

  1. 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.

@majestrate
Copy link
Contributor

majestrate commented Oct 12, 2018 via email

@cathugger
Copy link
Contributor Author

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).

@cathugger
Copy link
Contributor Author

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?)

@majestrate
Copy link
Contributor

majestrate commented Oct 12, 2018 via email

@cathugger
Copy link
Contributor Author

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"?

@majestrate
Copy link
Contributor

majestrate commented Oct 12, 2018 via email

@cathugger
Copy link
Contributor Author

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.

@majestrate
Copy link
Contributor

majestrate commented Oct 12, 2018 via email

@cathugger
Copy link
Contributor Author

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.

@cathugger
Copy link
Contributor Author

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

@despair86
Copy link
Contributor

despair86 commented Oct 12, 2018 •
edited
Loading

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

@neuroscr neuroscr added the enhancement New feature or request label Dec 4, 2018
@majestrate
Copy link
Contributor

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

@gh338
Copy link

gh338 commented Jul 19, 2019

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.

@neuroscr
Copy link
Contributor

neuroscr commented Sep 5, 2019

closing since we have ipv6 code now

@neuroscr neuroscr closed this as completed Sep 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@majestrate @neuroscr @cathugger @despair86 @gh338