Spurious libstd test failures on machines without IPv6 networking

[zackw]

I have IPv6 disabled on my office computer, because the router doesn't support it but glibc tries to use it anyway unless it's completely turned off. This causes a great many spurious failures in net::tcp and net::udp - they appear to be trying to use the IPv6 loopback address.

Please make the net tests check for whether the computer has a v6 loopback interface configured, and skip testing v6 if it doesn't.

[Hello71]

In 2018, you should never disable IPv6 globally. Maybe you don't have IPv6 connectivity, but there is basically never a good reason to permanently disable it, not least because it causes issues like this. If your "router" (gateway) is broken, you should preferably fix it, or at worst disable obtaining an IPv6 address in your networking software.

[zackw]

@Hello71 The sysdamins for my organization have informed me that IPv6 support is on their to-do list but I should not hold my breath because it will involve replacing hundreds of thousands of dollars' worth of gear.

"Disable obtaining an IPv6 address" is exactly what I have done. This has negative side effects (notably, the local resolver still queries for AAAA records, which get dropped on the floor at the organizational DNS server, causing all network connections to take longer) if I don't also disable IPv6 loopback.

[Hello71]

get dropped on the floor at the organizational DNS server

sounds like godawful "security" aka nobody will ever want to use anything other than HTTP over port 80. (the same garbage holding up TLS 1.3...) general-purpose DNS servers have absolutely zero legitimate reason to block unknown RR types.

regardless, I am told that the Linux sysctl to disable IPv6 does not affect glibc. on Windows, Microsoft says "IPv6 is a mandatory part of the Windows operating system". it follows that Rust should not add compatibility cruft for unnecessarily broken build machines.

[zackw]

Arguments from how someone's large organization's routers and DNS servers ought to be configured are unconvincing to me. They are configured in an IPv6-hostile manner and there's nothing whatsoever I can do about that. I do not think my situation is unique; in fact, I think it's rather more common than not.

Also, I find your tone unnecessarily hostile. You tell anyone that their development workstation is "unnecessarily broken", especially when the problem is due to something they have no control over, and they're liable to take their ball and go home.

[Hello71]

To be clear, I am saying that:

1. your DNS servers sound broken in a stupid way. this is not your fault personally, but unnecessarily impedes deployment of modern protocols like SCTP and TLS 1.3.

2. I don't understand what your (technical) problem is.

3. Because of 2, I don't understand what your workaround is, but it sounds like it either doesn't work at all or, alternatively, Rust shouldn't bother supporting it.

[zackw]

I don't understand what your (technical) problem is

The situation here seems to have improved since I originally reported this issue, and I may be able to turn my IPv6 loopback on again without problems, but I can't yet confirm that this leads to successful libstd test runs because currently x.py test src/libstd --stage 0 fails with an unrelated problem,

  Compiling std v0.0.0 (file:///.../rust/src/libstd)
error: the #[global_allocator] in this crate conflicts with global allocator in: std

But that's not the point.

I do not see the specific technical reasons why my computer, or any computer, may need to be configured without an IPv6 loopback address as relevant.

The request is for the libstd test suite to notice when the computer has been configured without IPv6, for whatever reason, and skip testing IPv6-dependent functionality. IPv4-only is a legitimate configuration - yes, even for development workstations - and should be supported. No networking at all, and IPv6-only, are also legitimate configurations that should be supported.

[Hello71]

Microsoft says that turning off IPv6 entirely is not supported for exactly the reason that testing every possible configuration is impossible, and even if it were possible, it's far too much work.

Besides, under your proposal, the build would contain possibly non-working IPv6 code. Unless you are proposing to disable IPv6 support entirely if the build machine does not support it, which sounds like a bad plan.