This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: ip_interface can't be broadcast or number net
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.4, Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: m01, ncoghlan, pmoody, python-dev, r.david.murray, Вячеслав
Priority: normal Keywords:

Created on 2014-11-14 23:04 by Вячеслав, last changed 2022-04-11 14:58 by admin.

Messages (5)
msg231194 - (view) Author: Вячеслав (Вячеслав) Date: 2014-11-14 23:04
ip_interface can't be network or broadcast address. Probably should throw an exception in such cases

>>> ip_interface(u'192.168.1.0/25')
IPv4Interface(u'192.168.1.0/25')

>>> ip_interface(u'192.168.1.127/25')
IPv4Interface(u'192.168.1.127/25')
msg231214 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-11-15 19:02
Well, it can be the network, even though it isn't typically (and some devices don't support it...I'm pretty sure I remember doing it on a Cisco, though I wouldn't swear to it without testing :).  Same is true for broadcast, though that would be *really* questionable and I doubt many devices support it.  (At least, I couldn't find any RFC that says those two addresses are actually reserved in all contexts).  

I know of two situations in which it is specifically not true: the simplest (which could be special cased) is a two ip (point to point) subnet.  The other is a "routed" subnet: a subnet where the subnet is routed to a router/firewall, and the router/firewall NATs those addresses to some internal addresses.  Conceptually, every IP in the subnet can be an interface IP.
msg231220 - (view) Author: Вячеслав (Вячеслав) Date: 2014-11-15 21:33
These addresses are used by each interface in the network and they can not be the address of the interface, of course have the technology ip-unnumbered. But it's more a special case.

but I was confused behavior:

>>> set(ip_network(u'192.168.1.0/29'))
set([IPv4Address(u'192.168.1.5'), IPv4Address(u'192.168.1.6'), IPv4Address(u'192.168.1.7'), IPv4Address(u'192.168.1.2'), IPv4Address(u'192.168.1.3'), IPv4Address(u'192.168.1.4'), IPv4Address(u'192.168.1.0'), IPv4Address(u'192.168.1.1')])


>>> for i in ip_network(u'192.168.1.0/29').hosts():
...     print i
...
192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.4
192.168.1.5
192.168.1.6
msg231222 - (view) Author: Вячеслав (Вячеслав) Date: 2014-11-15 21:52
Probably worth noting that network is unnumbered in ip_network and ip_interface functions. Based on this flag to decide whether there is a possibility to use the network address and broadcast address in the network
What do you think about this?
msg231260 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2014-11-16 23:52
The Interface classes are actually designed to cover any association of an IP address with a specific network, not just host interface addresses. We knew it was a slight misnomer when we chose it, but network and broadcast addresses weren't considered special enough to be worth separating out (beyond the distinction present in iterating over the whole network range vs just the host addresses).

It's relatively straightforward to write a helper function that only allows the creation of host interfaces:

    def host_interface(address):
        ifaddr = ip_interface(address)
        if ifaddr.ip == ifaddr.network.network_address:
            raise ValueError("'{}' is a network address".format(ifaddr)
        if ifaddr.ip == ifaddr.network.broadcast_address:
            raise ValueError("'{}' is a broadcast address".format(ifaddr)
        return ifaddr

I'm not sure if it's worthwhile to add such a helper function to the module itself.

One argument in favour of adding it is that it may help to emphasise that the normal ip_interface factory function and the *Interface class constructors are *not* restricted purely to host interfaces, and thus allow network and broadcast addresses to be associated with their corresponding network definition.
History
Date User Action Args
2022-04-11 14:58:10adminsetgithub: 67065
2014-11-16 23:52:59ncoghlansetmessages: + msg231260
2014-11-15 21:52:18Вячеславsetmessages: + msg231222
2014-11-15 21:33:25Вячеславsetmessages: + msg231220
2014-11-15 19:02:34r.david.murraysetnosy: + r.david.murray

messages: + msg231214
versions: + Python 3.4, Python 3.5, - Python 2.7
2014-11-14 23:04:39Вячеславcreate