homepage

Python 3.3/3.4 sometimes does not recognize a legitimate IPv6Network netmask:
$ python3
Python 3.3.5 (default, May 28 2014, 13:56:57) 
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ipaddress as ip
>>> nodecon = ip.IPv6Network('ff00::/ff00::')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/lib64/python3.3/ipaddress.py", line 2084, in __init__
 self._prefixlen = self._prefix_from_prefix_string(addr[1])
 File "/usr/lib64/python3.3/ipaddress.py", line 514, in _prefix_from_prefix_string
 self._report_invalid_netmask(prefixlen_str)
 File "/usr/lib64/python3.3/ipaddress.py", line 497, in _report_invalid_netmask
 raise NetmaskValueError(msg) from None
ipaddress.NetmaskValueError: 'ff00::' is not a valid netmask
>>> nodecon = ip.IPv6Network('ff00::/8')
>>> print(nodecon)
ff00::/8
>>> print(nodecon.with_netmask)
ff00::/ff00::
I get the same behavior on Python 3.4.2.

The doc is unhelpful on this, but looking at the implementation and tests, only a prefix length is allowed, not an expanded netmask. This would therefore be a feature request.

That's unfortunate. The library provides factory functions so v4 and v6 addresses/networks are easily handled together, and yet it seems to have been overlooked that you can do this:
ipaddress.ip_network('192.168.1.0/255.255.255.0') 
but not this:
ipaddress.ip_network('ff00::/ff00::')
I'll open up another issue for the docs, as they are not simply unhelpful, they're misleading, as the IPv6Network docs clearly say that you should be able to use an expanded netmask.

I don't know enough about IPv6 to give more insight (perhaps Peter Moody can answer), but the tests have this comment: 
# We only support CIDR for IPv6, because expanded netmasks are not
# standard notation.

> # We only support CIDR for IPv6, because expanded netmasks are not
> # standard notation.
Yes, that's correct. I can double check this, but when I wrote ipaddress, I had yet to encounter a v6 netmask in anything other than cider notation.

Hey Chris,
What's the usecase for this? the netmask notation doesn't appear to be common for v6 (at all), so I'm hesitant to add support for this if it's just something like an academic exercise.
Cheers,
peter

I understand the resistance; I'm fine closing this as "won't implement", though this is not for academic use. In a nutshell, my package currently has a set of classes to represent an SELinux policy, and the SELinux policy language represents networks with extended netmask[1]. I control the package, so I can change the internal representation from extended netmask to CIDR, so it's not the end of the world.
[1] example statement: nodecon ff00:: ff00:: system_u:object_r:multicast_node_t

If you have the ability to use cidr, then closing this as wontfix is my preference. I've heard that there might be some network vendors that are starting support the mask notation for v6 addresses though, so this may end up getting implemented at some point in future anyway.