jonson@SERVER.AF.MIL ("Lt. Matt Jonson") (08/28/90)
In message <63256@bu.edu.bu.edu> usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu (Kent England) writes: > I didn't see anybody cite chapter and verse of the Host Requirements RFC >and considering the hours spent on that fine document, I think it would >be a shame >not to cite the official bible of the Internet (ok, one of the bibles...): > >----------------------------- > From RFC 1122 Sec 3.2.1.3 Addressing: RFC-791 Section 3.2; > > "IP addresses are not permitted to have the value 0 or -1 for > any of the <Host-number>, <Network-number>, or <Subnet- > number> fields (except in the special cases listed above). > This implies that each of these fields will be at least two > bits long." >------------------------------ > [...] >I therefore conclude that a host part of zero is never a legal source address. >So I think the petitioner should change the addresses on his hosts and >not bother his >router vendor. Isn't the Host Requirements RFC wonderful? This only >took five minutes >to research and that included checking the commentary in RFC 1127. :-) And this is all correct, you cannot have a <Host-number> of 0. However, you can have a final OCTET of 0 legally if you are subnetting (for instance) a class B on LESS THAN 8 bits. For instance, 5 bit <Subnet-number> and 11 bit <Host-number> from class B: BBBBBBBB.BBBBBBBB.SSSSSHHH.HHHHHHHH 10000011.00111111.00001001.00000000 This should be a legal address, because it is on subnet 1, and is host #256. The dotted decimal notation is 131.63.9.0 !!! which is the type of situation that I believe the person who posted the question was talking about. This is a legal number, but there may be some old broken routers out there that still think it is bad because they don't know subnetting (?) Similary, one could generate an address that (dotted-decimally) ended in 255, that should also be technically legal, but may just as well be filtered by a gateway that didn't know any better. Conclusion: May be wise to avoid creating host addresses that have an all 1 or all 0 fourth octet if you don't have the time to hunt down routers that filter on what they assume is an errant broadcast. Contrarily, it would be nice if someone actively pursued broken implementations... (Lt) Matt Jonson AF DDN Program Office jonson@server.af.mil And yes, those were my words, not the government's. (They don't pay me enough to speak for them too)
bob@MorningStar.Com (Bob Sutterfield) (08/28/90)
I have adopted the habit of avoiding using as host addresses anything that, in any 8-bit aligned piece of the "host part" of an IP address, are 0x00, 0x01, 0xFE, or 0xFF. Such addresses may well be legal, particuarly when correctly interpreted in light of non-8bit subnet masking, but there's always the odd machine out there who wants to take things differently. If there will ever be disagreements they will be in the boundary conditions. It's quicker and easier to avoid problems in advance than to cite RFCs at the new box on the network. An exception can be observed in my adopted convention of numbering "things that are only gateways and perform no other `host' functions" as host 0x01. This hasn't yet proved to be a problem.
dls@mentor.cc.purdue.edu (David L Stevens) (08/28/90)
I've seen two articles now that suggest that it is legitimate to filter directed broadcasts if the gateway thought they were. Note that it is wrong to do so, at least for destinations, in the first place. It is perfectly legitimate for me to address a broadcast packet to a remote network. I could see where a gateway might arguably drop packets whose source address is a broadcast address, but that's a little more intrusive than I'd want a gateway to be. The host can and should take responsibility for that sort of checking. A gateway should just do ttl, checksum and routing and leave everything else alone. So even if these routers did have the right sense of what a broadcast packet on a remote network is, which they can't have, they should not be discarding those packets. -- +-DLS (dls@mentor.cc.purdue.edu)
mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) (08/29/90)
In article <13391@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
:
: I've seen two articles now that suggest that it is legitimate to
:filter directed broadcasts if the gateway thought they were. Note that it
:is wrong to do so, at least for destinations, in the first place. It is
:perfectly legitimate for me to address a broadcast packet to a remote network.
: I could see where a gateway might arguably drop packets whose source
:address is a broadcast address, but that's a little more intrusive than I'd
:want a gateway to be. The host can and should take responsibility for that
:sort of checking. A gateway should just do ttl, checksum and routing and
:leave everything else alone.
: So even if these routers did have the right sense of what a broadcast
:packet on a remote network is, which they can't have, they should not be
:discarding those packets.
:--
: +-DLS (dls@mentor.cc.purdue.edu)
I disagree - it is a perfectly legitimate function for routers to
perform message filtering. Before we hooked to the Internet, we set
up our routers to prohibit certain types of traffic - it was far
easier to manage the change in the one router than have to migrate it
through the entire net (dozens, nay scores, of machines). In
addition, the functionality we wanted to restrict we only wanted to
restrict to outsiders.
--
Dan Mercer
Reply-To: mercer@npdiss1.StPaul.NCR.COM (Dan Mercer)
"MAN - the only one word oxymoron in the English Language"dls@mentor.cc.purdue.edu (David L Stevens) (08/29/90)
In article <563@npdiss1.StPaul.NCR.COM>, mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) writes: > I disagree - it is a perfectly legitimate function for routers to > perform message filtering. ... Well, first of all, the original poster's description suggests that this is the default behaviour of the router, and not the result of some arbitrary packet filtering. Secondly, sure, you can filter packets and many routers will let you do that arbitrarily ("ok, no packets with a "7" in the 47th data byte-- I always hated those."]. The price you pay for that explicit nonconformance to the protocol is that you can't interoperate with other systems. IP doesn't include packet filtering and to the extent that you do it, you reduce the ability of your users to talk IP with other hosts. Certainly the more carefully you do it, the less impact it will have, but it's not free and if you don't consider all the legitimate uses that might be affected, your users lose. Following the spec, on the other hand, probably won't get you into trouble. I'm not a packet filtering fan... :-) And finally, in this case in particular (remote gateway), you CAN'T know whether the address is a broadcast address or not, since the mask isn't available to you. If you take the "we know better than you" approach and discard packets that look like they may use broadcast addresses, you won't be able to talk to perfectly legitimate, conforming, IP hosts. You'd get what you deserved, but your unsuspecting users and anyone who has to route through you would be the ones who really get it. The only conservative, and thus wise, way for a gateway to route a packet that has a different network number than any of its interfaces is to look at the piece it needs to for routing (first 2 octets for Class B) and leave the host part to the magic of gateways that know something about it. That keeps them from getting in the way when new things, like subnetting, come along. -- +-DLS (dls@mentor.cc.purdue.edu)