Home Original page

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

"Martin v. Löwis" martin at v.loewis.de
Sun Sep 27 21:50:09 CEST 2009 
>> 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?)

You would have to know either the broadcast address directly, or
the network (i.e. address and prefix length).

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

The one that says that the broadcast address is -1 (and 0 should
also be supported) is STD 3. The one that talks about 31-bit prefixes
(RFC 3021) is a proposed standard.

> RFC 3021 adds an odd wart to the "all ones" and "all zeros" functions
> (or perhaps only to "all ones"?).

To both: it allows them to be used as host addresses, even though STD 3
says that they are reserved and must not be assigned to hosts.

> 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"? 

For these, I would first like to find out what their specification
is.

Regards,
Martin
More information about the Python-Dev mailing list