https://docs.python.org/3.8/library/ipaddress.html

import ipaddress


ADDRESSES = [
    '172.16.254.00'
]

for ip in ADDRESSES:
    addr = ipaddress.ip_address(ip)
    if addr.version==4:
        {
            print("true")
        }
    else:
        {
            print("false")
        }
Screen Shot 2020-09-20 at 1 33 30 AM

I tried to validate an invalid IPv4 address using IPaddress library from py 3.8.6 but somehow it considers any address ending with "00" to be valid.

I hope this is helpful to the community please let me know if the issue is with validation from your end or a bug in the library.

@AnudeepBalla

Simplified:
>>> import ipaddress
>>> print(ipaddress.ip_address('172.16.254.00').version)
4

So your concern is that you think '172.16.254.00' (or equivalently, '172.16.254.0') shouldn't be treated as a valid IPv4 address. Is that correct?

Can you tell us why you think it's not a valid IPv4 address? I think everything is working correctly here.

Greetings,

Any Ip address containing 2 zeros or more are considered to be an invalid
IP address.

 '172.16.254.00' *is not* equivalent to '172.16.254.0'

I guess this small logic is causing the error

I hope it makes it clear from the below images.

Regards,
Raj.

[image: Screen Shot 2020-09-20 at 11.42.39 AM.png]
[image: Screen Shot 2020-09-20 at 11.42.31 AM.png]
[image: Screen Shot 2020-09-20 at 11.42.18 AM.png]
[image: Screen Shot 2020-09-20 at 11.42.09 AM.png]

On Sun, 20 Sep 2020 at 08:00, Eric V. Smith <report@bugs.python.org> wrote:

>
> Eric V. Smith <eric@trueblade.com> added the comment:
>
> Simplified:
> >>> import ipaddress
> >>> print(ipaddress.ip_address('172.16.254.00').version)
> 4
>
> So your concern is that you think '172.16.254.00' (or equivalently,
> '172.16.254.0') shouldn't be treated as a valid IPv4 address. Is that
> correct?
>
> Can you tell us why you think it's not a valid IPv4 address? I think
> everything is working correctly here.
>
> ----------
> nosy: +eric.smith
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue41820>
> _______________________________________
>

Please do not include screen shots in bug reports. They've unfriendly to people who use screen readers or other accessibility software. Instead, please copy and paste (or retype, if needed) the text into the comment section.

> '172.16.254.00' *is not* equivalent to '172.16.254.0'

Do you have an RFC or other document that makes that clear? I've never seen an IP address library that makes a distinction between '00' and '0'. But I'm happy to learn something new, if you can point to a standard.

If this were going to be an error, it would be in the call to ipaddress.ip_address() or its equivalent. It would raise ValueError, like it does for other strings that don't represent valid addresses. But for backward compatibility reasons, unless there's a standard that explicitly disallows .00, I doubt we'd change the code to raise an exception. And even if there were a standard that says .00 is not a valid address, I'd be reluctant to make a change here. We could potentially break people's code, and we'd need a very good reason to do that.

Also, is this causing you a practical problem? Is there somewhere you're getting a .00 address and you'd like to treat it as being invalid?

Why do you think it is invalid? What formal document specify this?

In contrary, there are examples of using 0-padded notation for IPv4 addresses (000.rrr.rrr.rrr, 128.000.rrr.rrr, 192.000.001.rrr and 224.000.000.000) in RFC 790.

That was the whole point I was trying to make that there were no references
that state .00 is equivalent to .0 and  if you would try any IP validator
or would check by any means you would find that the IP address is invalid.

I truly understand the point that you are trying to make but if my program
says a invalid IP address as valid I don't see how that helps.

I have checked almost every online IP validators to give me the same
INVALID as result for 172.16.254.00 while they say 172.16.254.0 is VALID.

On Sun, 20 Sep 2020 at 12:04, Eric V. Smith <report@bugs.python.org> wrote:

>
> Eric V. Smith <eric@trueblade.com> added the comment:
>
> Please do not include screen shots in bug reports. They've unfriendly to
> people who use screen readers or other accessibility software. Instead,
> please copy and paste (or retype, if needed) the text into the comment
> section.
>
> > '172.16.254.00' *is not* equivalent to '172.16.254.0'
>
> Do you have an RFC or other document that makes that clear? I've never
> seen an IP address library that makes a distinction between '00' and '0'.
> But I'm happy to learn something new, if you can point to a standard.
>
> If this were going to be an error, it would be in the call to
> ipaddress.ip_address() or its equivalent. It would raise ValueError, like
> it does for other strings that don't represent valid addresses. But for
> backward compatibility reasons, unless there's a standard that explicitly
> disallows .00, I doubt we'd change the code to raise an exception. And even
> if there were a standard that says .00 is not a valid address, I'd be
> reluctant to make a change here. We could potentially break people's code,
> and we'd need a very good reason to do that.
>
> Also, is this causing you a practical problem? Is there somewhere you're
> getting a .00 address and you'd like to treat it as being invalid?
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue41820>
> _______________________________________
>

Given that RFC 790 uses 000 as an octet (thanks Serhiy), I think the bug here, if there is one, is in the other validator that you're using. Without a standard saying not to accept 00 or 000, I think we won't make any change here.

I'm going to close this, for two reasons:
- RFC 790 uses 000 in examples, do I think ipaddress is doing the correct thing already.
- We'd be unlikely to change this in any event, for fear of breaking existing, working code.

@anudeepballa07: if you find an RFC or other authoritative source that says 00 or 000 are not to be used, feel free to reopen this issue and we can discuss next steps.

I'm also changing the title to make it easier to search for this issue in the future.

The first point should have been "RFC 790 uses 000 in examples, so I think ipaddress is doing the correct thing already."