Title: Python does not work on an IPv6 only host
Type: behavior Stage:
Components: Versions: Python 3.7, Python 3.6, Python 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: asdfasdfasdfasdfasdfasdfasdf, gregory.p.smith, loewis
Priority: normal Keywords:

Created on 2010-11-14 04:35 by asdfasdfasdfasdfasdfasdfasdf, last changed 2016-11-23 02:40 by gregory.p.smith.

Messages (3)
msg121174 - (view) Author: david (asdfasdfasdfasdfasdfasdfasdf) Date: 2010-11-14 04:35
(socket.gethostbyname  doesn't return an ipv6 address)
So just to start with I know the documentation says [0] "and getaddrinfo() should be used instead for IPv4/v6 dual stack support."
However, the getaddrinfo() method provides more information than required. Why can't getaddrinfo support ipv6 ? or a method for ipv6 added to the socket module to make getting a host address by name easier (for ipv6) ? 

[0] -
msg121185 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-11-14 10:30
Python has a policy of exposing low-level APIs as-is, i.e. the way the operating system implements them. gethostbyname is an old BSD socket API function that is limited to IPv4, and Python exposes it as such.

If you want another convenience function, I recommend to write it yourself, and then use it in your code.
msg281535 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2016-11-23 02:40
Reopening to expand upon this issue which is still a large problem:

If you run on an IPv6-only Linux host, the following standard library tests all fail:

test_asynchat, test_asyncio, test_asyncore, test_docxmlrpc, test_epoll, test_httpservers, test_logging, test_multiprocessing_fork, test_multiprocessing_forkserver, test_os, test_poplib, test_pydoc, test_robotparser, test_ssl, test_support, test_telnetlib, test_urllib2_localnet, test_urllib_response, test_uuid, test_xmlrpc

I won't attempt to paste all of the errors into here but the errors have a few themes, here's a couple examples:

ERROR: test_arp_getnode (test.test_uuid.TestUUID)
Traceback (most recent call last):
  File "lib/python3.4/test/", line 324, in test_arp_getnode
    node = uuid._arp_getnode()
  File "lib/python3.4/", line 364, in _arp_getnode
    ip_addr = socket.gethostbyname(socket.gethostname())
socket.gaierror: [Errno -2] Name or service not known

ERROR: test_getwelcome (test.test_poplib.TestPOP3Class)
Traceback (most recent call last):
  File "lib/python3.4/test/", line 246, in setUp
    self.server = DummyPOP3Server((HOST, PORT))
  File "lib/python3.4/test/", line 199, in __init__
    self.create_socket(af, socket.SOCK_STREAM)
  File "lib/python3.4/", line 289, in create_socket
    sock = socket.socket(family, type)
  File "lib/python3.4/", line 126, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
OSError: [Errno 97] Address family not supported by protocol

(yes I know those are from an old 3.4 test suite run but code inspection of 3.6 shows that the underlying issues appear to remain)

Someone will need to setup an IPv6 only host in order to work on these and can generate the full modern list of errors.

It appears we have things that explicitly use IPv4 specific socket flags when unwarranted or use old API calls that don't deal with IPv6 at all, and represent IP addresses as strings within most of our standard library rather than adopting our own high level ipaddress module for API compatibility reasons.  (see regarding TCPServer not supporting IPv6 at all)

Taking this on will keep Python relevant for the future without forcing people to jump through hoops or abandon the stdlib and only use third party networking libraries.
Date User Action Args
2016-11-23 02:40:04gregory.p.smithsetstatus: closed -> open

type: behavior

title: socket.gethostbyname doesn't return an ipv6 address -> Python does not work on an IPv6 only host
nosy: + gregory.p.smith
versions: + Python 2.7, Python 3.6, Python 3.7
messages: + msg281535
resolution: wont fix ->
2010-11-14 10:30:52loewissetstatus: open -> closed

nosy: + loewis
messages: + msg121185

resolution: wont fix
2010-11-14 04:35:17asdfasdfasdfasdfasdfasdfasdfcreate