Cyberduck Mountain Duck CLI

#8848 closed defect (fixed)

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

Reported by: richardvd Owned by:
Priority: normal Milestone: 4.7.1
Component: core Version: Nightly Build
Severity: normal Keywords: IPv6, routing
Cc: Architecture: Intel
Platform: Mac OS X 10.10

Description

Related to Ticket 8802.

r17562 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, r17652 correctly selects 'en0' for the IPv6 traffic. But f I enable Apple's BTMM (Back to My Mac), then r17652 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, r17652 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.

Change History (4)

comment:1 Changed on May 25, 2015 at 6:48:23 PM by dkocher

Add utun0 to blacklist of network interfaces in r17658.

comment:2 in reply to: ↑ description ; follow-up: Changed on May 25, 2015 at 6:53:13 PM by dkocher

Replying to 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 ?

comment:3 Changed on May 25, 2015 at 6:59:34 PM by dkocher

  • Resolution set to fixed
  • Status changed from new to closed

In r17659.

comment:4 in reply to: ↑ 2 Changed on May 25, 2015 at 8:59:39 PM by richardvd

Replying to 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)
Note: See TracTickets for help on using tickets.
swiss made software