[Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

[Guido van Rossum]

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
> (INADDR_BROADCAST). 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/)