jqj@HOGG.CC.UOREGON.EDU (07/08/88)
A typical situation for many of us is a subnetted class B network
running a variety of IP-based hosts, including many that are 4.3BSD and
4.2BSD based. In such an environment, one settable parameter on the
4.3BSD systems and others is the "broadcast address". There are many
possible values for this; I am curious what other sites set it to.
It is clearly desirable for all machines on a given subnet to agree on
the broadcast address. 4.xBSD generates ICMP errors or erroneosly
forwards Ethernet broadcasts with IP addresses it does not recognize as
IP broadcasts; even the latest Tahoe 4.3BSD code recognizes as IP
broadcasts only {net,0,0}, {net,subnet,0}, 255.255.255.255, 0.0.0.0,
and the set broadcast address (and not both {net,-1,-1} and
{net,subnet,-1} even though both are legal!). Earlier releases
recognize only a subset of these. By getting everybody to agree you'll
eliminate all those erroneous ICMP unreachables and ARP requests for
your subnet broadcast address. You might even avoid a serious
broadcast storm...
What is not clear is what in an imperfect world to try to get
everybody to agree to. Some possibilities:
{net,0,0} the 4.2BSD standard, and still the SunOS 4.0
default (according to "man ifconfig"). Some
people use this for backwards compatibility
with 4.2, but it is a violation of the IP spec
and 4.2 implementations are disappearing (right?).
{net,subnet,-1} i.e. the subnet broadcast address. The 4.3
Tahoe default if you set a subnet mask but no
broadcast address. Not too good if you plan to
change your subnet mask or if there is confusion
over what it is (e.g. if you're trying heterogenous
sized subnets).
{-1,-1,-1} i.e. the local broadcast address. Some IP
implementations insist on generating this address,
so it might also be a reasonable choice of standard.
{net,-1,-1} i.e. the network broadcast address. Has the
advantage of being immune to mis-set subnet mask
problems. But not a good choice if you have
routers that explode letter bombs and you want
broadcasts to be subnet-local.
In the past, I've standardized on {net,subnet,-1}. Charles Hedrick, the
first of us to have analyzed the broadcast storm problem, has in the past
recommended {net,0,0} as a concession to 4.2BSD [Chuck, am I taking your
name in vain?].
So, my questions: (1) What have other sites standardized on? (2) What
are the disadvantages, if any, of standardizing on the subnet broadcast
address?BILLW@MATHOM.CISCO.COM (William Westfield) (07/09/88)
I recomend AGAINST using the subnet in the broadcast address. This makes it impossible for systems to send a broadcast until after they know the proper netmask. If the system is a diskless machine trying to boot off the net, it would normally do this by sending a broadcast ICMP MASK REQUEST or BOOTP. But it can't do this until AFTER it knows the broadcast address... Using the local broadcast address (-1, or 0) seems the best solution, though it seems to annoy older unix systems. Bill Westfield cisco Systems. -------
hedrick@aramis.rutgers.edu (Charles Hedrick) (07/09/88)
I don't think there is a single answer to the best broadcast address.
In general I recommend 255.255.255.255 on networks where the machines
can deal with it. On those where they can't, probably {net,0,0} is
the only one that will work. We're slowly being able to move to
255.255.255.255.jgd@csd1.milw.wisc.edu (John G Dobnick) (07/10/88)
In article <12412750860.11.BILLW@MATHOM.CISCO.COM>, BILLW@MATHOM.CISCO.COM (William Westfield) writes: [... elided text...] > Using the local broadcast address (-1, or 0) seems the best solution, ^^^^^^^^^^ [...] > Bill Westfield > cisco Systems. In the interests of precision, that should read (255.255.255.255, or 0.0.0.0). On *my* machine, "-1" is 255.255.255.254, as it is 1's complement. This is an easy trap to fall into, and vendors especially should be particularly careful about this. -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee UUCP: <backbone>!uwvax!uwmcsd1!jgd INTERNET: jgd@csd4.milw.wisc.edu All the world's not a VAX, nor is it all 2's complement! -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee UUCP: <backbone>!uwvax!uwmcsd1!jgd INTERNET: jgd@csd4.milw.wisc.edu "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight." -- William Safire
gamiddleton@watmath.waterloo.edu (Guy Middleton) (07/10/88)
This is an important question for us, as we plan to convert our campus to a
new set of addresses very soon (next week). Once we decide on a broadcast
address, it will be difficult to change our minds. I had been planning on
using the current 4.3 default of (I believe) {net,subnet,-1}, but recent
comments seem to indicate that 0xffffffff may have advantages for diskless
machines trying to discover their identities. More last-minute advice would
be appreciated; after next Sunday, there will be no going back for us...
-Guy Middleton, University of Waterloo Institute for Computer Research
gamiddleton@math.waterloo.edujgd@csd1.milw.wisc.edu (John G Dobnick) (07/10/88)
I insert foot in mouth in article <6184@uwmcsd1.UUCP>, where I say: > This ["-1" is all 1 bits] is an easy trap to fall into, and vendors > especially should be particularly careful about this. Jon Postel in article <8807090341.AA04490@bel.isi.edu> replies: > ... please read RFC-1009 pages 14, 15, 35, 36, 44, 45. Indeed, RFC 1009 states in the text that "-1" is "all one bits". I stand corrected on this matter. Assuming "-1" is "all ones" is, to me, a 2's complement bias. Coming from a 1's complement environment, I misinterpreted this and shot my mouth off. Sorry, folks. I'm just learning about all this network stuff. [I still have a problem with some wording in RFC1009, but am not sure this is the proper place to raise it. Can someone advise me on this?] -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee UUCP: <backbone>!uwvax!uwmcsd1!jgd INTERNET: jgd@csd4.milw.wisc.edu -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee UUCP: <backbone>!uwvax!uwmcsd1!jgd INTERNET: jgd@csd4.milw.wisc.edu "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight." -- William Safire
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (07/10/88)
The difficulty (for UNIX systems at least) with choosing 255.255.255.255
(or 0.0.0.0 or {net,constant,constant}) as a broadcast address arises
when you try to put broadcast-based applications on multi-homed hosts or gw's.
To broadcast on a particular net -- or for that matter on all nets -- what
address should be used? Using the {net,subnet,constant} form at least ensures
that every interface has a distinct broadcast address and that a route exists
for that address.
It might be possible for applications to send to {net,subnet,constant}
and for the IP layer to detect that a broadcast was intended and translate
it into some other broadcast address before transmission. This would
be pretty disgusting, however, and is anyway not done by any software I know of.
Do any of the sites choosing 255.255.255.255 as a standard broadcast address
have a solution?mogul@DECWRL.DEC.COM (Jeffrey Mogul) (07/12/88)
First, try to follow the robustness principle: hosts should accept AS BROADCASTS all the possible (i.e., legal or formerly legal) broadcast addresses. For example, on a Class A network with an 8-bit subnet field, these addresses might be expected: SCOPE ILLEGAL LEGAL ---------------- ---------------- ------------------ wildcard 0.0.0.0 255.255.255.255 net-broadcast net.0.0.0 net.255.255.255 subnet-broadcast net.subnet.0.0 net.subnet.255.255 Note that this is especially important because there are some things that a host must never do in response to a broadcast packet (such as send an ICMP Destination Unreachable), and so these must all be recognized as broadcasts (this is even more important than accepting them). Second, hosts should never send all-zeros addresses (unless the LAN administration has decided to temporarily disobey the standard until they can find a vendor that sells proper software). Third, in a world where rules 1 and 2 are obeyed, most hosts should be configured to send broadcasts to 255.255.255.255, to avoid having to configure one more thing on a per-host basis. The exception here is that on multihomed hosts (and on gateways) there may be applications which want to broadcast to one, but not all, of the connected subnets. On these hosts, broadcasts should be addressed to the subnet-broadcast addresses. Fourth, I don't know of any implementations of the reverse-path-forwarding mechanism I proposed in RFC922, so there is probably no reason to use a net-broadcast address on a subnetted network. Again, this assumes that everyone is playing by the rules. Finally, it appears true that on most LANs, rules 1 and 2 are violated by at least one host. In such cases, the best solution is to pick a broadcast address that all the hosts can live with, and resign yourself to the occasional broadcast storm or dropped broadcast. An important point is: there is a big difference between what a host should recognize/accept (everything), what a host should send (legal things), and what should be used (the most legal thing for which every host won't screw up and probably will accept). -Jeff Mogul (mogul@decwrl.dec.com)
dab@ALLSPICE.LCS.MIT.EDU (07/12/88)
>> First, try to follow the robustness principle: hosts should accept >> AS BROADCASTS all the possible (i.e., legal or formerly legal) >> broadcast addresses. Hosts should also accept AS BROADCASTS any packet that was sent to the link layer broadcast (and mulitcast???) address regardless of what the IP address was. David Bridgham
hedrick@athos.rutgers.edu.UUCP (07/13/88)
You asked how to use a broadcast address of -1 on hosts with more than one interface. I don't know whether this is what actually happens in 4.3BSD, but I know what *should* happen. The application should use net.subnet.-1. This lets the routing code choose the right interface and route. If it turns out to be a directed broadcast to some remote network, the packet should be sent to the right gateway using that address as the destination. If it turns out the net.subnet is directly connection, when the packet is about to go out the interface (right before generating the checksum, hopefully), the address should be changed to the preferred broadcast address for that interface. That way they can all be -1 or 0, etc., but your application can still specify which interface to use. This seems to be what cisco gateways do. We set the broadcast addresses to 255.255.255.255, but it never has trouble forwarding directed broadcasts, so it must be able to tell which interface to use.
karn@thumper.bellcore.com (Phil R. Karn) (07/13/88)
The "correct" IP address to use in broadcast packets seems to have become a perennial issue. So once again I'll point out that, in my opinion, hosts should treat any packet as a broadcast if it comes in with the LINK level broadcast address (e.g., all 1's on Ethernet). The IP destination address field in such packets should be completely IGNORED. An "out of band" indication of whether a given packet is a broadcast or not should be passed up along with the packet to the IP layer, and from there to the various transport protocols. (Certain protocols, e.g. TCP, have good reason to refuse to respond to broadcast packets). This is the only way I know to keep gateways from forwarding broadcasts from hosts with the "incorrect" IP broadcast address. When you think about it, much of an IP header (including the destination address field) is meaningless in the context of a broadcast packet anyway since broadcasts are not supposed to pass through gateways. Phil
morgan@Jessica.UUCP (07/13/88)
What applications use the IP broadcast address? - RL "Bob"
braden@VENERA.ISI.EDU (07/15/88)
Assuming "-1" is "all ones" is, to me, a 2's complement bias. Coming from a
1's complement environment, I misinterpreted this and shot my mouth off.
Sorry, folks. I'm just learning about all this network stuff.
[I still have a problem with some wording in RFC1009, but am not sure this
is the proper place to raise it. Can someone advise me on this?]
--
John G Dobnick
Computing Services Division @ University of Wisconsin - Milwaukee
UUCP: <backbone>!uwvax!uwmcsd1!jgd
INTERNET: jgd@csd4.milw.wisc.edu
John,
We plead guilty of 2's-complement bigotry. I actually did not know there
are still 1's complement machines in the world, in fact...
Please send along any and all comments and suggestions on RFC0-1009 to
us. We are starting to think about the first revision.
Bob Braden
braden@isi.edumogul@DECWRL.DEC.COM (Jeffrey Mogul) (07/15/88)
Phil Karn writes:
In my opinion, hosts should treat any packet as a broadcast if it
comes in with the LINK level broadcast address (e.g., all 1's on
Ethernet). The IP destination address field in such packets should
be completely IGNORED.
I'm not sure this is precisely right. There are really two different
reasons to recognize incoming packets as broadcast:
(1) Proper broadcasts should be accepted and passed to the
appropriate receiver process.
(2) Certain things should never be done with packets that are
received as broadcasts, link-level or IP-level.
"BOOTP" packets, etc., come under reason 1. Not sending ICMP
error messages in response to broadcasts comes under reason 2.
The remaining question is: what should be done with a packet that
is received as a link-layer broadcast but is addressed to an IP
address which is not believed to be a broadcast address. Simply
"ignoring" the IP address would be a mistake because the packet
might be meant for a different host. In my opinion, a (non-gateway)
host should simply drop any packet with a destination that is not
either one of its own IP addresses, or one of its IP broadcast
addresses. In addition, all hosts (gateway or not) must remember
whether a packet was received as a link-level broadcast, to avoid
violating the rule in reason 2 (above).
So what should a gateway do if it receives an IP packet that it
would normally forward, but the packet was a link-level broadcast?
Drop it? Forward it? Forward it and send a redirect, if necessary?
The conservative approach would be "drop it", but perhaps someone
is trying to discover a gateway in a brain-damaged sort of way.
Again, simply "ignoring" the IP address is probably wrong.
Suggestions?braden@VENERA.ISI.EDU (07/15/88)
>> First, try to follow the robustness principle: hosts should accept >> AS BROADCASTS all the possible (i.e., legal or formerly legal) >> broadcast addresses. Hosts should also accept AS BROADCASTS any packet that was sent to the link layer broadcast (and mulitcast???) address regardless of what the IP address was. David Bridgham Well, now, I would not put it quite that way. To be an acceptable IP broadcast datagram, it must have a recogizable IP broadcast address in its destination field. The problem we need to solve is the havoc (broadcast storms, etc) created by datagrams which arrive by local network broadcast but do not have a recognizable IP broadcast address. The discussions in the IETF Host Requirements Working Group have concluded that the best thing to do with such datagrams is SILENTLY IGNORE THEM. Bob Braden
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (07/16/88)
> *Excerpts from ext.in.tcp-ip: 12-Jul-88 Re: default broadcast address* > *Charles Hedrick@princeto (991)* > I don't know whether this is what actually happens in > 4.3BSD, but I know what *should* happen. The application should use > net.subnet.-1. > That way they can all be -1 or 0, etc., but your application can still > specify which interface to use. I don't think this is appropriate for all implementations. The ip layer shouldn't be second guessing the application. Some applications may want to send to -1 and some may want to send to net.subnet.-1. 4.3BSD is broken because it doesn't allow an application to send to -1 yet still specify which interface to use. It could use some out-of-band indication such as bind() or an ioctl(). I.e. if you bind() to the address of a particular interface (vs. INADDR_ANY) and send to -1 it could route the packet to the interface of the address to which you are bound. Drew
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (07/17/88)
That's a great idea! (To select an interface for broadcast by bind()ing the socket first.) You could even handle the fact that there's no route for e.g. 255.255.255.255, by invoking the check-for-bound-socket- on-broadcast code only when the route lookup fails. If on the other hand the route lookup succeeds, you must have specified some net-specific destination. Stuart
ian@spider.UUCP (07/22/88)
I'm surprised to hear that RFC 922 isnt generally supported (I implemented it for our routers). RFC 1009 certainly pushes it, it's straightforward to implement, and without it you can't handle network broadcasts over subnets. I can see an issue with network broacasting from an embedded gateway or multihomed host with two (or more) interfaces onto subnets of the same network, viz. what IP source address do you use for the multiple outgoing datagrams? If a network broadcast is transmitted on an unbound socket, do you use the local IP address for each interface? In this case you get different datagrams transmitted on each interface. A consequence of the suboptimality of reverse path forwarding is that hosts on some subnets will receive one datagram (with varying IP source address) and hosts on others may receive two datagrams with different IP source addresses. The number of datagrams and source address of the datagrams received by a particular host may change as the routing tables change. Multihomed hosts suffer from identity crises, I suppose.
mckee@MITRE.ARPA (H. Craig McKee) (07/29/88)
>> First, try to the robustness principle: hosts should accept >> AS BROADCASTS all the possible (i.e., legal or formerly legal) >> broadcast addresses. >Hosts should also accept AS BROADCASTS any packet that was sent to the >link layer broadcast (and mulitcast???) address regardless of what the >IP address was. David Bridgham >Well, now, I would not put it quite that way. To be an acceptable >IP broadcast datagram, it must have a recogizable IP broadcast address >in its destination field. The problem we need to solve is the havoc >(broadcast storms, etc) created by datagrams which arrive by local >network broadcast but do not have a recognizable IP broadcast address. >The discussions in the IETF Host Requirements Working Group have >concluded that the best thing to do with such datagrams is SILENTLY >IGNORE THEM. >Bob Braden From a security aspect: Anything that can cause havoc (broadcast storms) can cause denial of service. Anything that may be silently ignored (by some folks) has the potential of being used (by other folks) as part of a covert channel. From a management aspect: I hope the people working on network management will devise procedures that will allow a site or network manager or security officer to create an audit record of "normal" and abnormal errors, at every layer in the stack. Regards - Craig