[Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library (original) (raw)

Guido van Rossum guido at python.org
Sun Sep 27 18:37:40 CEST 2009

On Sun, Sep 27, 2009 at 12:41 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

Guido van Rossum wrote:

I realize I'm late to this party, but this is just a naming issue, right? Not really (AFAIU).

For any network, there are two special addresses, one with the last bits all zeros, one with the last bits all ones. We can call them A and B, or network and broadcast, or zeros and ones, or whatever we care. But their definitions are two well-defined functions for all networks (assuming a network is defined as an IP address and a number of bits), even if in an extreme case the functions return the same value. For the broadcast address, it's different, since you might also use it in programming (i.e. when sending broadcasts).

So there is no need to look up the broadcast address in the configuration? Don't you have to look up the rest of the network configuration too? (Or otherwise how do you know your network address and the value of /N?)

Now, it seems that people will typically use undirected broadcasts (INADDRBROADCAST). However, I assume there are also applications for directed broadcasts; in this case, it would matter to know the broadcast address of a network.

I don't know, and it seems you are not familiar with an actual case either. I would assume that apps doing such low-level work would have direct access to the complete network configuration, of which the broadcast address to use would be a separate argument. The ipaddr library seems most useful for doing manipulations and computations on addresses and networks that may bear no relationship to the current host's configuration -- e.g. off-line verification of firewall configurations, or whatever.

What is actually configured on a particular host to be the broadcast address is a separate issue, even if by convention in most cases it is given by one of the above functions -- the network object doesn't care, the configuration object is something else (and outside the scope of this PEP). It's a little bit stronger than convention; there are RFCs saying that the all-ones (-1) address has to be the broadcast address.

Sure, but what is the status of those RFCs? (Plenty of RFCs are unimplemented or superseded by others etc.)

In any case we seem to agree that 'broadcast' is a fine name for the 'all ones' address so I don't want to argue this point any further. :)

This is like saying that it is out of scope of the socket protocol whether TCP is the IP protocol 6, and that individual hosts may do it differently - yes, they may, but then everything stops working.

Well, except that if al hosts on a closed network were to define their alternate value in the appropriate header, then everything would work (within that closed network!), even Python (which gets the TCP value from the system header too).

But I don't think that that is relevant to ipaddr, which has to be able to make decisions about arbitrary IP addresses and networks without having access to the hosts or their configurations. It can only look at the syntax.

IMO "real life examples" don't matter for the definitions of the functions That I agree with.

and I would personally be happy to name them network and broadcast, since I know their definitions and their typical uses and these match pretty closely. The expectation should be clearly set that these are pure functions though and do not imply knowledge of the configuration of any given host. That I also agree with. However, there is this issue of /31 networks, where an 8-year-old RFC specifies how to do broadcasts on these. I think RFCs should be considered wherever applicable.

Considered wherever applicable, yes. I'm assuming you're talking about RFC 3021 -- which says "standards track" but I can't find whether it is actually a standard or how widespread its implementation is. It might well be obsolete by now, or widely ignored, or irrelevant outside a few drivers. Another question is whether it always applies when a /31 network is used. If not, then we're back to the situation where we can't know the configuration, and declaring the RFC applicable in all cases doesn't make it so.

RFC 3021 adds an odd wart to the "all ones" and "all zeros" functions (or perhaps only to "all ones"?). If after further examination of the facts we find that it should be honored, then what do we do for .network and .broadcast on a /32 "network"? Is that an error or should it just return the one IP address of which the "network" consists?

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list