I tested it again (up-to-date Leap 42.1, lftp version 4.6.4.) I no longer have IPv6 disabled on this machine, as the bug which made me do that was fixed meanwhile. With "set dns:order inet", only the ipv4 address is tried, as expected. Without it (default behavior), the ipv6 address is tried first, fails ("Network unreachable") and lftp immediately falls back to the ipv4 address (which works.) This is the right behavior, as ipv6 is not configured on this machine. Now I disabled IPv6 to test this specific bug again (unchecked the "Enable IPv6" option in the yast network module) and restarted the machine. lftp still tries IPv6 first, and that fails with "Cannot assign requested address" as mentioned in the original bug report. It does NOT fall back to IPv4, even though there was an IPv4 address is the list for the target host. This is the key problem as far as I'm concerned. If lftp gets a list of possible addresses for the target host, it should try them all, and only give up if they all fail (or all hope is otherwise lost.) I think we want this commit from upstream: https://github.com/lavv17/lftp/commit/58bfcfc2b00c6f3524ed4988ba7c5f4cd6867cfe This commit is upstream since lftp v4.7.2, which would explain why you don't have the problem on Tumbleweed. Can we get it backported to Leap 42.1 and 42.2? And I don't think we want to change the address order. If lftp wants to try IPv6 first, that's fine, as long as it falls back to IPv4 as needed. (Maybe whoever resolves the host name should not return IPv6 addresses to the caller in the first place, I don't know what is considered the correct behavior in this case.)