Consider flagging ListenOptions.Listen(IPAddress.Any)

[amcasey]

Background and Motivation

On a machine that supports IPv6, listening to Any, rather than IPv6Any will either not work or be slower than necessary. For HTTP/1.x and 2/0, a name like localhost will resolve to [::1], which won't be accepted by the server, forcing a retry with 127.0.0.1 (i.e. failed attempt before each connection).

For HTTP/3.0, [::1] will fail and there won't be a retry, so the connection will fail.

Requested here.

See also #58094, #58171, https://github.com/dotnet/runtime/issues/108259

Proposed Analyzer

Analyzer Behavior and Message

We could probably get away with flagging every usage and letting users disable it on IPv4-only machines. Having said that, a nicer solution might be to have the analyzer detect IPv6 support.

Category

• [ ] Design
• [ ] Documentation
• [ ] Globalization
• [ ] Interoperability
• [ ] Maintainability
• [ ] Naming
• [x] Performance
• [ ] Reliability
• [ ] Security
• [ ] Style
• [x] Usage

Severity Level

• [ ] Error
• [ ] Warning
• [x] Info
• [ ] Hidden

Usage Scenarios

options.Listen(IPAddress.Any, 5001, listenOptions =>
{
    listenOptions.UseHttps();
    listenOptions.Protocols = HttpProtocols.Http1AndHttp2AndHttp3;
});

Risks

If a server specifically wants to reject IPv6 requests, such an analyzer would just be an irritation. It could, however, be disabled.

[david-acker]

Would it be appropriate for the analyzer to check for IPv6 support, given that the machine the analyzer runs on won’t necessarily be the machine the app is deployed to?

[amcasey]

Good point. Probably best to just always report the diagnostic and let users disable it if they know it doesn't apply.