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.

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

IPv6 (non link-local) should be routed by the OS #8848

Closed
cyberduck opened this issue May 25, 2015 · 4 comments
Closed

IPv6 (non link-local) should be routed by the OS #8848

cyberduck opened this issue May 25, 2015 · 4 comments

Comments

@cyberduck
Copy link
Collaborator

7ee63cc created the issue

Related to [8802 Ticket 8802].

039d455 has fixed the 'no route to host' issue when connecting to IPv6-only hosts. However, the way it is currently implemented does not work for all cases.

How it currently works (as I understand it): The application scans all network interfaces, and the first one that is not on a blacklist and seems IPv6-capable will be used. The problem is that the application does not know (and should not know) about the routing table and routing policies of the OS, and therefore often makes the wrong decision.

For example, on a MacBook Air with no IPv6 interfaces other than the onboard Wi-Fi, d8613dd correctly selects 'en0' for the IPv6 traffic. But f I enable Apple's BTMM (Back to My Mac), then d8613dd selects 'utun0' although that interface doesn't provide any internet access. Result: 'no route to host'.

Another example, if I hook up an Ethernet connection 'en3', it becomes the default gateway for IPv6 so I expect FTP traffic to go through that interface. However, d8613dd will still select the 'en0' interface (Wi-Fi).

To my understanding, interface selection by the user is only relevant for the non-routable link-local IPv6 addresses (fe80::/64), and all other routing decisions should be left to the OS.

Please fix this by using the current automatic interface selection mechanism only for link-local IPv6 addresses where no interface name was appended to the address, and letting the OS do the routing for all other addresses.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Add utun0 to blacklist of network interfaces in 6d65ea5.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [8848 richardvd]:

Please fix this by using the current automatic interface selection mechanism only for link-local IPv6 addresses where no interface name was appended to the address, and letting the OS do the routing for all other addresses.

Do you mean to exclude IP6 address from the workaround that have a zone id set that references an interface name using the <address>%<zone_id> syntax ?

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In e2e2640.

@cyberduck
Copy link
Collaborator Author

7ee63cc commented

Replying to [comment:2 dkocher]:

Do you mean to exclude IP6 address from the workaround that have a zone id set that references an interface name using the <address>%<zone_id> syntax ?

What I mean is:

  1. if it is a link-local address (i.e. within fe80::/64) and it has the %zone_id suffix: use that interface
  2. all other IPv6 cases: let the OS do its job (don't bother selecting and binding to an interface yourself)

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant