Title: ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
Type: behavior Stage: needs patch
Components: Documentation Versions: Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Joel Croteau, docs@python, eric.smith, ncoghlan, ned.deily, pmoody, serhiy.storchaka
Priority: normal Keywords: 3.2regression

Created on 2019-03-20 23:40 by Joel Croteau, last changed 2019-04-07 11:49 by ncoghlan.

Pull Requests
URL Status Linked Edit
PR 12577 merged python-dev, 2019-03-27 02:05
Messages (8)
msg338514 - (view) Author: Joel Croteau (Joel Croteau) * Date: 2019-03-20 23:40
I understand to a certain extent the logic in not allowing IPv4 octets that might ambiguously be octal, but in practice, it just seems like it creates additional parsing hassle needlessly. I have never in many years of working on many networked systems seen anyone use dotted octal format, it is actually specifically forbidden by RFC 3986 (, and it means that the ipaddress module throws exceptions on many perfectly valid IP addresses just because they have leading zeroes. Since the module doesn't support dotted octal or dotted hex anyway, this check seems a little pointless. If nothing else, there should be a way to disable this check by specifying that your IPs are in fact dotted decimal, otherwise it seems like it's just making you have to do extra parsing work or just write your own implementation.
msg338694 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2019-03-23 19:35
I agree that this is not a useful check.
msg339204 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2019-03-30 14:53
New changeset e653d4d8e820a7a004ad399530af0135b45db27a by Nick Coghlan (Joel Croteau) in branch 'master':
bpo-36384: Remove check for leading zeroes in IPv4 addresses (GH-12577)
msg339205 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2019-03-30 14:57
I've merged the change for Python 3.8 (thanks Joel!).

I'm not sure whether to classify it as an enhancement or as an interoperability bug fix, though, so I've put the status to pending and added Ned to the nosy list to get his thoughts as the Python 3.7 RM.
msg339206 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-03-30 15:44
ipaddress is behaving as documented:

"The following constitutes a valid IPv4 address:

A string in decimal-dot notation, consisting of four decimal integers in the inclusive range 0–255, separated by dots (e.g. Each integer represents an octet (byte) in the address. Leading zeroes are tolerated only for values less than 8 (as there is no ambiguity between the decimal and octal interpretations of such strings). [...]"

I can sort of understand imposing that restriction in a Python 2 world where leading zeros implied octal and Python 3 outright rejects such forms of integers to avoid the ambiguity.  That said, there's no particular reason why the components of an IPv4 string acceptable to ipaddress *have* to follow the same rules so I'm +0 on making the change at all.  It's a bit of a stretch to consider it a bug when it appears to be behaving as documented but I would expect such a change to fix more problems than causing them so I'm OK if you want to backport it.

But, in any case, the documentation for 3.8 and/or 3.7 needs to be updated.
msg339210 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-03-30 16:15
See also the article "Ping and FTP Resolve IP Address with Leading Zero as Octal" (

This is still true in Windows 10.

So it is safer to reject IPv4 addresses with leading zeros that can be ambiguously interpreted. Otherwise this can create a security hole.
msg339211 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2019-03-30 16:16
I think it should be 3.8 only, and the docs should be updated. Apologies for not catching that earlier: I searched via Google, which was a mistake.
msg339572 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2019-04-07 11:49
The recommended handling in the article that Serhiy mentions is to strip the leading zeroes, which the ipaddress module will still do - it's only being made more tolerant on input. That means it will become usable as a prefilter step (pass string with potentially leading zeroes to ipaddress, get string with no leading zeroes out).

So that means the one part we missed is the docs update (together with a versionchanged note in the module docs themselves)
Date User Action Args
2019-04-07 11:49:32ncoghlansetnosy: + docs@python
messages: + msg339572

assignee: docs@python
components: + Documentation, - Library (Lib)
2019-03-30 16:16:17eric.smithsetmessages: + msg339211
2019-03-30 16:15:02serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg339210
2019-03-30 15:44:32ned.deilysetstatus: pending -> open
messages: + msg339206

keywords: + 3.2regression, - patch
resolution: fixed ->
stage: resolved -> needs patch
2019-03-30 15:12:39xtreaksetstatus: open -> pending
2019-03-30 15:12:26xtreaksetstatus: pending -> open
nosy: + ned.deily
2019-03-30 14:57:36ncoghlansetstatus: open -> pending
resolution: fixed
messages: + msg339205

stage: patch review -> resolved
2019-03-30 14:53:51ncoghlansetmessages: + msg339204
2019-03-27 06:32:51serhiy.storchakasetnosy: + ncoghlan
2019-03-27 02:05:56python-devsetkeywords: + patch
stage: patch review
pull_requests: + pull_request12521
2019-03-23 19:35:05eric.smithsetnosy: + eric.smith
messages: + msg338694
2019-03-21 08:16:51SilentGhostsetnosy: + pmoody

versions: - Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.9
2019-03-20 23:40:09Joel Croteaucreate