Skip to content
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

Open
ghost opened this issue Nov 14, 2014 · 5 comments
Open

ip_interface can't be broadcast or number net #67065

ghost opened this issue Nov 14, 2014 · 5 comments
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@ghost
Copy link

ghost commented Nov 14, 2014

BPO 22876
Nosy @ncoghlan, @bitdancer

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:

assignee = None
closed_at = None
created_at = <Date 2014-11-14.23:04:39.773>
labels = ['type-bug', 'library']
title = "ip_interface can't be broadcast or number net"
updated_at = <Date 2014-11-16.23:52:59.760>
user = None

bugs.python.org fields:

activity = <Date 2014-11-16.23:52:59.760>
actor = 'ncoghlan'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2014-11-14.23:04:39.773>
creator = '\xd0\x92\xd1\x8f\xd1\x87\xd0\xb5\xd1\x81\xd0\xbb\xd0\xb0\xd0\xb2'
dependencies = []
files = []
hgrepos = []
issue_num = 22876
keywords = []
message_count = 5.0
messages = ['231194', '231214', '231220', '231222', '231260']
nosy_count = 6.0
nosy_names = ['ncoghlan', 'pmoody', 'r.david.murray', 'python-dev', 'm01', '\xd0\x92\xd1\x8f\xd1\x87\xd0\xb5\xd1\x81\xd0\xbb\xd0\xb0\xd0\xb2']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue22876'
versions = ['Python 3.4', 'Python 3.5']

@ghost
Copy link
Author

ghost commented Nov 14, 2014

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')

Repository owner added stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Nov 14, 2014
@bitdancer
Copy link
Member

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.

@ghost
Copy link
Author

ghost commented Nov 15, 2014

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

@ghost
Copy link
Author

ghost commented Nov 15, 2014

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?

@ncoghlan
Copy link
Contributor

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.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

3 participants