On Wed, Aug 19, 2009 at 4:45 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
> No, I just said its conventionally used as that but its not definition
> of a broadcast (in fact you can have any valid host address defined
> as broadcast as long as all members of the network agree on that)

You could, but then you are violating existing protocol specifications.

RFC 1122 mandates, in sections 3.2.1.3 and 3.3.6, that certain addresses
MUST be understood as broadcast addresses, by all nodes (independent of
configuration).

I think a Python IP address library should conform to all relevant RFCs.

Yes, but section 3.3.6 also states:

There is a class of hosts (4.2BSD Unix and its derivatives, but not 4.3BSD) that use non-standard broadcast address forms, substituting 0 for -1. All hosts SHOULD recognize and accept any of these non-standard broadcast addresses as the destination address of an incoming datagram. A host MAY optionally have a configuration option to choose the 0 or the -1 form of broadcast address, for each physical interface, but this option SHOULD default to the standard (-1) form.

So it sounds like doing what I suggested earlier (default to [-1], allow for customization) is actually required by the RFC :-).  Although it does sound like the RFC only requires that you be able to customize to [0] rather than [-1], rather than any address.  In practical terms though I believe it is possible to do as Tino suggests and configure any crazy address you want to be the broadcast address (or addresses, even) for a network.

I think setting the broadcast address to something else just does not need to be supported.

It is unusual, but frankly, needing to actually do operations on broadcast addresses at all is also a pretty unusual task.  Broadcast itself is a somewhat obscure corner of networking.  I suspect that in many deployments that need to write significant code to deal with broadcast addresses, rather than the usual default stuff, funky configurations will actually be quite common.

I would not be surprised to find that there are still some 4.2BSD VAXes somewhere doing something important, and some Python may one day be called upon to manage their networks.