tar@ksuvax1.cis.ksu.edu (Tim Ramsey) (08/28/89)
Hello,
I have a LAN (Ethernet) with a mixture of systems on it. Some of the
systems are running 4.2 based TCP/IP, others are running 4.3 based
TCP/IP. I can't change the broadcast address (129.130.0.0) on the 4.2
systems. The broadcast address on the 4.3 systems is 129.130.255.255.
This is really no problem, except that the 4.2 systems don't see
broadcast packets from the 4.3 systems (the 4.3 systems do see the
4.2 broadcast packets).
I'd like to change the 4.3 broadcast address to 129.130.0.0 so everyone
can see everyone. But is this likely to break anything?
A brief list of my systems:
4.3-like networking:
Sun 3s (SunOS 4.0)
VAX 11/780 (More/bsd (4.3BSD + NFS))
Harris HCX-9 (HX/UX 4.0 (4.3 sorta + NFS))
4.2-like networking:
ATT 3B2s (SysV 3.0 + WIN/3B 1.1)
ATT 3B15s (SysV 2.1 + WIN/3B 1.1)
Will changing the broadcast address break things like YP or NFS?
Thanks for any help. Please email responses and I'll post a summary.
Tim
--
- VAX it to me at - Dept. of Computing and Information Sciences
BITNET: tar@KSUVAX1 Kansas State University
Internet: tar@ksuvax1.cis.ksu.edu Manhattan, KS 66506
UUCP: ...!{rutgers,texbell}!ksuvax1!tar (913) 532-6350dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) (08/28/89)
Tim, Let me try out a potential Universal Truth, and see if anyone objects: If you have 4.2-based TCP implementations, then you MUST use zero-based IP broadcasting, with zeroes in the host portion of the IP address. Dave
mogul@decwrl.dec.com (Jeffrey Mogul) (08/29/89)
dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
Let me try out a potential Universal Truth, and see if anyone objects:
If you have 4.2-based TCP implementations, then you MUST use
zero-based IP broadcasting, with zeroes in the host portion of the
IP address.
Ok, I'll bite. How about:
If you have 4.2-based TCP implementations, then you MUST
fix them, or stop trying to support broadcast applications.
Since there isn't much point to broadcasting in 4.2BSD except for
routed (install a default route to a neighboring gateway) and rwhod
(who needs it, anyway?), I wouldn't worry about it. The latest
draft of the Host Requirements document is a little slippery ...
it says that hosts MUST recognize legally-addressed broacasts
(all-ones style) but then it mentions that a host MAY be allowed to
send all-zeros style broadcasts. This seems contradictory, but it
probably reflects the most Universal Truth of all: do what you have
to do, if you can't do what's right.
-Jeffdcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) (08/29/89)
The issue of the Host Requirements document's stance on zero- vs. ones-based IP broadcast (now, is everyone clear that we are talking about the bits that are in the destination field of the IP header, only, and not the source, and definitely not any of the bits in the ethernet header?) that Jeff Mogus raises is a sore point. The HR committee wrestled with it. The bottom line is that if you want to configure for the use of zero-based, then you can, and still be conformant with the HR doc. The key point is that under all circumstances, even when you configure for zero-based, you MUST STILL be able to recognize ones-based. (Yess, that means that a zero-based net must have all of its hosts checking both for zeroes in the host field, as well as all-ones.) Dave
karn@jupiter (Phil R. Karn) (08/31/89)
I've said it before, and I'll say it again... the proliferation of IP broadcast formats, the confusion about which to use, and the broadcast storms that result from all this, tells me that there is a fundamental flaw in how broadcasting is presently handled in IP. I believe that the determination of whether a packet is a broadcast packet should NOT be made from the IP destination address field, but rather from the link layer destination field. If a datagram comes encapsulated in an Ethernet frame with a destination of all 1's, then IP should treat it as a broadcast packet, regardless of what it says in the IP destination field. This requires an "out of band" flag (indicating whether the link level destination field contained a broadcast or multicast address) to be passed up along with the packet so that IP's behavior can be appropriately influenced. For example, ICMP would use this bit to suppress ICMP error messages. Broadcast forwarding storms can't happen since a hardware broadcast address on an IP datagram implies an IP broadcast, and IP would never try to forward such a packet. If you also pass this flag up to the transport layer, then it's easy for TCP to ignore people trying to telnet to the broadcast address. Other protocols, e.g., UDP, would accept broadcast packets. Phil
dls@mentor.cc.purdue.edu (David L Stevens) (08/31/89)
But but but... What about directed broadcasts? If you remove the idea of a broadcast address from IP, you lose this. Maybe you see that as an advantage... :-) I'm not really sure what you mean by "making it a flag", though; I presume you mean in the uppermost interface of IP, but perhaps you mean something in the packet. (?) The latter wouldn't seem much different than a broadcast address, since all but the "real" addressee would reject it, unless it were some special address, anyway. I have to admit I can't think of any (honorable, anyway) uses of directed broadcast, but it's not clear to me that there are none. With things on the Internet becoming more numerous and harder to find, I expect directed broadcast and multicast addressing will become more useful in the coming years... -- +-DLS (dls@mentor.cc.purdue.edu)
karn@ka9q.bellcore.com (Phil Karn) (08/31/89)
> What about directed broadcasts? If you remove the idea of a broadcast >address from IP, you lose this. Maybe you see that as an advantage... :-) > I'm not really sure what you mean by "making it a flag", though; I >presume you mean in the uppermost interface of IP, but perhaps you mean >something in the packet. (?) The latter wouldn't seem much different than >a broadcast address, since all but the "real" addressee would reject it, >unless it were some special address, anyway. By "flag", I mean that the subnetwork should pass an indication of whether the packet was received on a hardware broadcast or multicast address up to the IP layer along with the packet, e.g., as a second argument in a function call. My scheme doesn't really preclude multicasting. My main goal was to find a reliable way to stop broadcast and ARP storms even when other hosts have totally broken notions of the IP broadcast address. As long as the hardware multicast flag is available to IP, the IP layer can suppress the ICMP messages and packet forwarding that cause broadcast storms; it can still look at the IP destination address if it wants to see if the packet should be accepted locally. Phil
mckee@MITRE.MITRE.ORG (H. Craig McKee) (08/31/89)
A few months ago Phil Karn argued that any given host should one IP address, not one per network interface. I would appreciate some tutorial words on the relative merits of single vs multiple IP addresses. "An enquiring mind" - Craig
CERF@A.ISI.EDU (09/01/89)
Phil, isn't it a consequence of your suggestion that no IP packet could be broadcast outside of a given network since packets lose their link levels as they move through a gateway? Vint
kasten@interlan.interlan.COM (Frank Kastenholz) (09/01/89)
The use of an indication passed up from the datalink layer that indicates whether the packet was sent to the datalink broadcast or not, while useful, does not cover the entire problem. There are network configurations where, in effect, you do not have data link level packet addressing - for example, if a network was built out of point to point links (slip, etc, etc). At a previous company I worked at, we offered a product that allowed one to build TCP/IP networks between mainframe hosts using serial point to point links. All addressing was carried in the IP header. ALL decisions as to the destination of the packet were made SOLELY on the basis of the IP header. I think that the preferred solution is to FIX the problem. Cheers Frank Kastenholz Racal InterLan
medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (09/02/89)
Vint, I feel the same way as Phil does. If you get a packet recieved via link level broadcast, you should NEVER forward it. If it is a packet that is trying to do directed broadcast (always questionable in my opinion), then that packet should have been unicast to the gateway in question, not broadcast. If you do things this way, you stomp on almost all the broken cases, and still have the flexibility to do directed broadcast, if you think this is a good thing. In most implementations that don't support this, you'd probably end up modifying device drivers, but I feel this is well worth it. The reason we have so many problems with broadcasts in that in most implementations, you end up throwing away info you hear at layer 2, and then trying to make up for it by using some incomplete hueristic at layer 3. This is a case where violating layering by passing info from layer 2 to layer 3 wins big. Thanks, Milo
dls@mentor.cc.purdue.edu (David L Stevens) (09/02/89)
Since Phil Karn will point it out, I will first; over such a SLIP link, where link-level addresses are implicit, you don't have broadcasts, anyway. From PK's second posting, it seems to me that he isn't so radical as I thought in that (and I know I'll be corrected if wrong) I THINK he was suggesting an additional flag (only) and not a replacement for IP broadcast/ multicast addressing. That seems perfectly reasonable to me and would allow traps for "telnet <broadcast addr>" without losing anything else. On the topic of single IP address per host: I used to think so too, but I suspect it would result in routing chaos and poor choices in other ways. Multi-connected hosts would likely suffer unnecessary outages or (just as bad) poor routing decisions (close hosts going the long way around) because of it. Hosts on the same network, but with different network addresses would suffer from different levels of service-- a nightmare to keep straight-- because distant gateways have incomplete or inconsistent information about the "different" networks. After all, the whole point of IP addresses is to make routing easy; if everything else works, humans shouldn't even have to deal with them... Finally, directed broadcasts (again) break; suppose you have a network where every host on it is a gateway and each's IP address is taken from its other network. You have a network that is not addressable, so, though you could send packets to individual hosts, you could not broadcast to all of them with one packet, like you can now. -- +-DLS (dls@mentor.cc.purdue.edu)
CERF@A.ISI.EDU (09/02/89)
Milo, I understand your point. Something still seems to be missing. Suppose the intent is to do directed broadcast (we can argue separately about whether this is a good idea - I'm prepared to come to the conclusion that it isn't and that the intent is better served with multicast). The target of the broadcast may be at the far end of the Internet. One would have to somehow identify the target net, for routing purposes, and the also indicate that the packet is to be broadcast there. This information needs to be contained in the destination IP address, because that is all that survives as the packet is encapsulation and decapsulated on its journey through an indeterminate number of nets and routers. The only way to achieve this is to have the destination IP address show the target net and the "rest" show "broadcast." If the source is on a LAN, the packet clearly should NOT show a level two "broadcast" indication at the LAN level, since the intent is to broadcast only at the destination. Multicasting is more complex because the multicast address format in IP is not network specific, so more machinery is needed. I agree that it is never appropriate to resend or forward a packet marked "broadcast" at level two. Are we in disagreement at this point? Vint
CSYSMAS@OAC.UCLA.EDU (Michael Stein) (09/02/89)
> On the topic of single IP address per host: I used to > think so too, but I suspect it would result in routing chaos > and poor choices in other ways. Multi-connected hosts would > likely suffer unnecessary outages or (just as bad) poor routing > decisions (close hosts going the long way around) because of > it. Really? I always thought it was the other way around. Right now my TCP connection is dead if my route fails to a milti-homed host even if another route (to a different IP address) existed since TCP connections are bound to an IP address pair, and NOT a host. Isn't this an "unnecessary outage"? > Hosts on the same network, but with different network > addresses would suffer from different levels of service-- a > nightmare to keep straight-- because distant gateways have > incomplete or inconsistent information about the "different" > networks. That's a deficiency of the current routing implementations. ("it's a routing problem, not an addressing problem"). > After all, the whole point of IP addresses is to make > routing easy; if everything else works, humans shouldn't even > have to deal with them... It seems to me that the point of IP addresses is to avoid having to place a route in each packet, instead only one value is needed to indentify the target host. Again note that TCP binds connections to IP addresses (not hosts) and each UDP packet is also bound that way. Why should a PARITAL path failure cause the data to be dropped? I think that this whole area is just one aspect of the general "IP routing problem". > Finally, directed broadcasts (again) break; suppose you > have a network where every host on it is a gateway and each's > IP address is taken from its other network. You have a network > that is not addressable, so, though you could send packets to > individual hosts, you could not broadcast to all of them with > one packet, like you can now. What about a multi-cast group address (or whatever it's called)? Again since each one of those hosts is on multiple "networks" I would assume that they are ALL involved in the routing protocols on each of their connected networks (including comparing the metrics of each) in making their routing decisions. All we need is a complete routing protocol.....
romkey@asylum.SF.CA.US (John Romkey) (09/03/89)
In article <8909011945.AA00826@cincsac.arc.nasa.gov> medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes: >The reason >we have so many problems with broadcasts in that in most implementations, >you end up throwing away info you hear at layer 2, and then trying >to make up for it by using some incomplete hueristic at layer 3. This >is a case where violating layering by passing info from layer 2 to layer >3 wins big. I agree. I like being able to keep around control information about received packets. In my recent designs for IP implementations, I've always made sure there was a way for layer 2 to mark a packet as broadcast so layer 3 could then decide what not to do with it. I do outgoing broadcast the same way (with a different bit). Keeping around timestamps can also be useful.
dls@mentor.cc.purdue.edu (David L Stevens) (09/03/89)
Re: "what about a multicast group." You can't. That's my whole point. Multicast, broadcast and host addresses all have an IP network part and if it's a collection of hosts (multicast or broadcast), they have to have the same IP network part (otherwise you can't route there!). Thus, you can't address a set of machines on the same physical network with different IP network parts. If you still can't see that, try it. Set up 3 networks, A, B and C. The gateway on A and C have the A and C IP net numbers and are the only ones on B; B has no IP net number. How do you address a broadcast packet for "B" (ie, to go to both A and C gateways) in your scheme? And I'll turn it around, since you don't seem to agree that routing is more of a problem with single IP addresses. What do you gain from having IP addresses identify "machines."? Right now, I can debug routing problems by depending on the fact that I can address individual interfaces. If you take that away from me, shouldn't there be a reason? Further, user-level programs like gated, can choose route advertising using correct masks [what is the netmask on one of these proposed multi-IP-address networks?] and special processing per interface based on high-level things, like IP network numbers, and not low level things, like interface device numbers. You can (and should) already have a single hostname for the multiple IP addresses on a multihomed host, so you can always use names or, for that matter, pick any one of the IP addresses. What do you gain by making me lose flexibility? From where I sit, it looks like a gratuitous change that would break lots of things that you haven't thought about. Things that I haven't thought about yet, either. And what you gain you could get (if you really wanted it) by using the IP address you have to get a DNS canonical name and then using the canonical name to get an IP address (not necessarily the same one you started with). Every interface address, with this, would get you to a single of the interface addresses and you wouldn't break all of the goodies I've grown fond of. We'd both be happy. Right? -- +-DLS (dls@mentor.cc.purdue.edu)
amanda@intercon.uu.net (Amanda Walker) (09/03/89)
In article <3842@mentor.cc.purdue.edu>, dls@mentor.cc.purdue.edu (David L Stevens) writes: > Multicast, broadcast and host addresses all have an IP network part and if > it's a collection of hosts (multicast or broadcast), they have to have the > same IP network part (otherwise you can't route there!). Actually, from what I understand of the current state of IP multicasting, IP multicast groups do *not* have an IP network part--they are class D addresses. For them to work across gateways, the gateways have to (a) know about multicast groups and (b) have a protocol by which to communicate current multicast routing informatin to and from other gateways. Aside from that, I pretty much agree that "one IP address per interface" is a reasonable thing to do. For one thing, it lets subnetting work... -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda -- "The trouble with doing something right the first time is that nobody appreciates how difficult it was" --Walt West
nelson@sun.soe.clarkson.edu (Russ Nelson) (09/03/89)
In article <8909011945.AA00826@cincsac.arc.nasa.gov> medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:
If you get a packet recieved via link level broadcast ..
you end up throwing away info you hear at layer 2, and then trying
to make up for it by using some incomplete hueristic at layer 3. This
is a case where violating layering by passing info from layer 2 to layer
3 wins big.
But are you *really* violating layering? All you're passing is an
indication that the packet in question was broadcast, not *how* it was
broadcast. You can get *too* silly about layering. After all, if you
don't pass any information at all, you have *perfect* information
hiding between layers. :-)
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])|(70441.205@compuserve.com)|
(Russ.Nelson@f360.n260.z1.fidonet.org)|(BH01@GEnie.com :-)medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (09/04/89)
Vint, I understand your point, and don't think we disagree. A packet received via link level broadcast should NEVER be forwarded. I don't think anyone disagrees with that. But the only way I can think of to verify that is to tag the packet at link layer as recieved by broadcast. As for what happens at the remote end of the packet's travel, well, that gets hairy. If you support the concept if directed broadcast (which, as I've said before, I do not), then the packet's destination IP address should probably be set to the all 1's network broadcast or subnet broadcast address. Clearly, you can't send to a subnet broadcast address without knowing the mask, and while you there are hacks you can perform, such as sending an ICMP netmask request message to one of the gateways on that net (or a host for that matter), they are all inadequate. For one thing, you have to deal with the existance of variable length subnet masks, and that means that there may not be one subnet mask for the entire network. While this typically hasn't been the case so far, routing protocols like OSPF are being implemented that support that functionality. Then you have to worry about how to find a gateway or host on the piece of plumbing you are trying to get to, and you may not be able to figure that without a priori knowledge... All this means you basically have to settle for directed network broadcast, if that. I think all this shows is that directed broadcast is a flawed concept, at least given the current way addressing works in the Internet. I think multicasting is really the right way to go, and gateway vendors should put their emphasis into that approach, and put the issue of directed broadcast to bed. All this directed broadcast discussion is really orthogonal to the issue of link level broadcast tagging. You can still have directed broadcast even if you do link level tagging. As far as I am concerned, there is no way you can make sure you don't forward broadcast packets without doing that tagging. Gateway vendors who don't implement tagging aren't being 1009 compliant. Thanks, Milo
medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (09/04/89)
Well, I think you can legitimately say that link level tagging as we are discussing does violate layering in that it is passing info about link level info to the network layer. As I understand it, you can pass all the info you want to an upper layer, as long as you don't pass info that is only known at your layer. Consider passing link level MAC addresses to IP, or passing IP checksum info to the application. Granted, these are extreme examples, but it does make the point. This is why the ISO model is a model, and should not be construed as an implementation guide :-)... In general, all the layers in the world won't help you unless you use common sense. Thanks, Milo
pprindev@wellfleet.com (Philip Prindeville) (09/05/89)
At great risk of being flamed at, what do people think of the idea of multihomed hosts advertising host routes split-horizon? That way, if the network that host H's interface H1 goes down, H1 will be advertised (and reachable) via interface H2..Hn. Supposedly the number of multihomed hosts (and the number of interfaces they have) is not a significant number (is it MKL?), so this should not add much overhead... -Philip
tom@wcc.oz (Tom Evans) (09/08/89)
In article <3801@mentor.cc.purdue.edu>, dls@mentor.cc.purdue.edu (David L Stevens) writes: > I have to admit I can't think of any (honorable, anyway) uses of > directed broadcast, but it's not clear to me that there are none. Running AppleTalk over IP may not be an honorable thing to do to an IP network, but there's a lot of us doing it. Anyone who finds a better way of doing this (i.e. eliminating the broadcasts) is going to have a lot of ROMS to swap :-). Guess who finds out that a network is using a broken mix of 4.2 1nd 4.3 Broadcasts? Me, and everyone else who tries to use an existing "working" IP network for AppleTalk networking. tom@wcc.oz.au