New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ip_interface can't be broadcast or number net #67065
Comments
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') |
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. |
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 |
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 |
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. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: