Dual IPv4 and IPv6 support in Flask applications

Question

Would it be possible to run Flask to listen in both IPv4 and IPv6 (i.e. dual IP stack)? As far as I checked it is possible to run either in IPv4 using:

app.run(host='0.0.0.0', port=port, debug=True)

or IPv6 using

app.run(host='::', port=port, debug=True)

but I haven't find a way of running in both at the same time (it is possible to have an instance of my Flask application listening to IPv4 and another instance listening to IPv6, but both cannot listen to the same port).

Thanks!

Update (additional info):

Followingt Sander Steffann comments (thanks!), I have started my app listening in IPv6:

* Running on http://[::]:1028/
* Restarting with reloader

Then test with IPv6 and IPv4 curls:

curl -g [::1]:1028/notify
curl 127.0.0.1:1028/notify

getting respectively:

::1 - - [10/Feb/2014 12:04:51] "GET /notify HTTP/1.1" 200 -
::ffff:127.0.0.1 - - [10/Feb/2014 12:05:03] "GET /notify HTTP/1.1" 200 -

My interpretation of the second line is that "somebody" (the OS? the underlying networking libraries in which Flask relies upon?) is converting the IPv4 request to IPv6 request. However, I understand that is not the same that supporting IPv4 "natively" in a classical dual stack setup, i.e. I would have expected something linke this (that is what I get when I run my application (Running on http://0.0.0.0:1028/)

127.0.0.1 - - [10/Feb/2014 12:05:03] "GET /notify HTTP/1.1" 200 -

Answer 1

What happens is that the operating system automatically attaches incoming IPv4 requests to the listening IPv6 socket. The IPv4 address is mapped to an IPv6 address by prefixing it with ::ffff:. Therefore an incoming IPv4 connection from 127.0.0.1 looks like it is coming from IPv6 address ::ffff:127.0.0.1.

From the client's point of view it is talking to an IPv4 server. The client cannot tell the difference. From the server's point of view everybody is connecting using IPv6. The operating system performs the mapping between IPv4 packets and the IPv6 software.

The effect of this is that you can develop software without manually having to deal with dual stack programming. All software can be written for IPv6 and deal with all addresses as IPv6 addresses. This can simplify the code (no need to deal with having both a listening IPv4 and a listening IPv6 sockets etc.) while still providing a full dual-stack experience to the 'outside'.

So your service is fully dual-stack as seen from outside your system. In the application itself you will see the whole world represented with IPv6 addresses though, like you show in your log file. That usually doesn't cause any problems. It might affect the way you handle ACLs, logging and other things like that though.

Answer 2

Unfortunately, while Linux uses mapped IPv4 addresses to qualify "::", this does not work on several other IPv6 stacks, such as on Microsoft Windows. "::" will bind to the IPv6 address family, as for security reasons, Windows and other IPv6 stack implementors have decided to against mapping IPv4 addresses into the IPv6 address space, unless an application especially signals to do so. The rationale here, as far as I understand the discussion, is that otherwise unexpected IPv4 connectivity would happen that could undermine ACLs, or other application-layer security mechanisms.