On Azure deployment, getting "Unable to bind to http://localhost:9410 on the IPv6 loopback interface."

[kirk-marple]

On the first time I deployed my .NET Core Web API to Azure, I noticed this in my logs.

Obviously just a warning, but it's binding to localhost while on Azure, which seemed a little odd, so I thought I'd ask about it.

From global.json:
"version": "1.0.0-preview2-003121"

And I'm using 'net452' frameworks.

  "Timestamp": "2016-07-20T16:42:54.8896127+00:00",
  "Level": "Warning",
  "MessageTemplate": "Unable to bind to http://localhost:9410 on the IPv6 loopback interface.",
  "Exception": "System.AggregateException: One or more errors occurred. ---> Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -4089 EAFNOSUPPORT address family not supported\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.Check(Int32 statusCode)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.tcp_bind(UvTcpHandle handle, SockAddr& addr, Int32 flags)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvTcpHandle.Bind(ServerAddress address)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.TcpListener.CreateListenSocket()\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Listener.<>c.<StartAsync>b__6_0(Object state)\r\n   --- End of inner exception stack trace ---\r\n   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)\r\n   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.KestrelEngine.CreateServer(ServerAddress address)\r\n   at Microsoft.AspNetCore.Server.Kestrel.KestrelServer.Start[TContext](IHttpApplication`1 application)\r\n---> (Inner Exception #0) Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvException: Error -4089 EAFNOSUPPORT address family not supported\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.Check(Int32 statusCode)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.Libuv.tcp_bind(UvTcpHandle handle, SockAddr& addr, Int32 flags)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Networking.UvTcpHandle.Bind(ServerAddress address)\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.TcpListener.CreateListenSocket()\r\n   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Listener.<>c.<StartAsync>b__6_0(Object state)<---\r\n",
  "Properties": {
    "SourceContext": "Microsoft.AspNetCore.Server.Kestrel",
    "MachineName": "RD000D3A124D8B",
    "ThreadId": 1
  }

[davidfowl]

To azure using what? Azure app service?

[kirk-marple]

Correct, yeah. Azure App Service. Freshly created a new App Service, and published from VS.

[davidfowl]

What does your Program.Main look like

[vmykhaylovskiy]

I'm getting the same warning message on Azure App service. I'm using 'net46' frameworks with 1.0.0-preview2-003121 sdk.

Here is what my Program.Main looks like.

    public class Program
    {
        public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .UseKestrel()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseIISIntegration()
                .UseStartup<Startup>()
                .Build();
            host.Run();
        }
    }

[kirk-marple]

Same here... just the default from the template.

    public class Program
    {
        public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .UseKestrel()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseIISIntegration()
                .UseStartup<Startup>()
                .Build();

            host.Run();
        }
    }

[davidfowl]

Which default template? Are you saying, the default template for ASP.NET Core ( .NET Framework) with no changes doesn't work on azure websites?

[kirk-marple]

Using Templates/Visual C#/.NET Core/ASP.NET Core Web Application (.NET Core), and selecting Web API.

It's not that it doesn't work, the Web API runs fine on Azure, after publishing.

I just noticed that warning in the log data, and thought it may be an concern, even though it doesn't affect the functionality of the Web API.

[davidfowl]

Are you running .NET Core or .NET Framework? You mentioned that you were using net452. Why did you pick .NET Core if that's the case?

[kirk-marple]

Right now, using the .NET Core project.json model (see attached example), but running net452 framework. Started this project last year during early DNX days, and been focusing on net452 for a stable baseline before going back and migrating to .NET Core runtime. The new project model works great, so didn't want to have to redo everything if we went to .NET Core runtime in future.

We also publish packages from our .NET Core projects and use them in .csproj projects (like on Service Fabric) where needed. So that part works well today.

project.json.txt

[halter73]

@kirk-marple Kestrel binding to localhost is expected since Azure App Services use IIS as a reverse proxy in front of Kestrel on the same "machine". IIS uses an available port (in this case 9410) to communicate to Kestrel.

All the way until RC2, we would only try to bind to the IPv4 loopback address (127.0.0.1) when binding to "localhost", so you likely wouldn't have seen this warning. Starting in 1.0.0, we try to bind to the IPv6 loopback address as well ([::1]). It seems that Azre App Services doesn't allow binding to ([::1]).

I think that it makes sense for UseIISIntegration to specify http://127.0.0.1:[port] so you don't see this warning, since it seems it uses IPv4 anyway. @Tratcher what do you think?

[muratg]

This issue was moved to aspnet/IISIntegration#239

[nulltoken]

@halter73 Could you please explain the current status of that issue? It's been closed on Jul, 2016. Then, later you've set a milestone for it.

Is this still opened and going to be fixed?

Or is the workaround you've proposed inhttps://github.com/aspnet/IISIntegration/issues/239#issuecomment-245061642 the way to solve it?

Sorry for the questions. I'm just trying to get a better understanding of the status of this as I'm also facing it (and trying to reduce the noise in my logs...)

[halter73]

This 2.0 change should clean up your logs by not logging the exception stack trace with the warning when Kestrel attempts to bind to IPv6 loopback in the Azure App Service environment. Hopefully this is enough noise reduction in you logs since it's now just a one line warning when your App starts.

The hacky workaround I gave is probably still the best way to completely get rid of the warning. That or wait for the App Service environment to support IPv6.

[nulltoken]

@halter73 Thanks a lot for this detailed answer 💟

That or wait for the App Service environment to support IPv6.

@davidebbo Is there any issue I could subscribe to to be notified when this is ready?

[davidebbo]

@nulltoken looks like https://feedback.azure.com/forums/34192--general-feedback/suggestions/17459872-azure-app-service-should-support-ipv6-address tracks this.

[nulltoken]

@davidebbo Voted and subscribed!