mf@ircam.ircam.fr (Michel Fingerhut) (08/26/90)
Our LAN is a class B network, 129.102.0.0, and I had the unfortunate idea to choose *legal* IP numbers for some of our main hosts of the form 129.102.nn.0, (nn != 0). It's legal for a machine, since the HOST part, nn.0, is definitely NOT zero. Turns out some major gateways (sorry, no names) filter out such numbers, thinking these are broadcasts or some such. Well, they are not. I can see 3 solutions: 1. Changing the numbering scheme of our (several dozen) machines. 2. Changing the RFC describing the internet addressing scheme 3. Fixing those gateways. So, what about (3), guys 'n gals, before I suggest (2) is done?
emv@math.lsa.umich.edu (Edward Vielmetti) (08/27/90)
In article <1990Aug25.220042.29632@ircam.ircam.fr> mf@ircam.ircam.fr (Michel Fingerhut) writes:
1. Changing the numbering scheme of our (several dozen) machines.
2. Changing the RFC describing the internet addressing scheme
3. Fixing those gateways.
Only a dozen machines? You are using name servers, right? Change
the numbers, it's a lot easier than changing the code...
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
(who is going to help change the numbers of 100's of hosts in the
next week or so as we get off of a class A net onto a class B)perand@admin.kth.se (Per Andersson) (08/27/90)
In article <EMV.90Aug26134330@stag.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes: >(who is going to help change the numbers of 100's of hosts in the > next week or so as we get off of a class A net onto a class B) Just both of you be careful if you have diskless clients. At least in the sun case it tftp:s the image whos filename is the IP-adress in hex. Maybe we should compose a list for 'How to do it' Per ( Migrating a class A and two class C nets to a B net someday soon.... ) -- --- Per Andersson Royal Institute of Technology, Stockholm, Sweden perand@admin.kth.se, @nada.kth.se
gamiddle@maytag.waterloo.edu (Guy Middleton) (08/27/90)
In article <1990Aug26.171641.14037@cs.umn.edu> peiffer@cs.umn.edu (Tim Peiffer (The Net Guy)) writes: > > I disagree. The same set of documents known as RFC's also describe > subnetting practices. It lists nn.0 as host '0' of subnet 'nn'. > Therefore the host part is zero. BTW, do not forget the host > numbered 255. This is only true if you use a subnet mask of 255.255.255.0; if your subnets use (for example) nine bits for a host-part, nn.0 is fine. Also, nothing in the RFCs obliges anybody to use subnets.
david@twg.com (David S. Herron) (08/27/90)
In article <1990Aug26.171641.14037@cs.umn.edu> peiffer@cs.umn.edu (Tim Peiffer (The Net Guy)) writes: >In article <1990Aug25.220042.29632@ircam.ircam.fr> mf@ircam.ircam.fr (Michel Fingerhut) writes: >>(nn != 0). It's legal for a machine, since the HOST part, nn.0, is definitely >>NOT zero. > > I disagree. The same set of documents known as RFC's also describe > subnetting practices. It lists nn.0 as host '0' of subnet 'nn'. > Therefore the host part is zero. BTW, do not forget the host > numbered 255. But .. But ... Subnet numbers don't have to be on 8 bit boundries. Sounds to me as if the routers in question are assuming them to *BE* on 8 bit boundries just like you are. Or the network in question might not be subnetted at all. It's not very correct for a router to assume such things for networks it isn't attached to. On the other hand if it does know the subnet mask and broadcast address for a subnet then it's fair for it to filter out broadcasts from that subnet. -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
kwe@bu-it.bu.edu (Kent England) (08/27/90)
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."
------------------------------
The special cases are:
(a) { 0, 0 } [only during initialization]
(b) { 0, <Host-number> } [only during initialization]
(c) { -1, -1 } [limited bcast; never source-addr]
(d) { <Network-number>, -1 } [directed bcast; never source-addr]
(e) { <Network-number>, <Subnet-number>, -1 } [directed
bcast; never source-addr]
(f) { <Network-number>, -1, -1 } [directed bcast; never
source-addr]
(g) { 127, <any> } [loopback addr; never outside a host]
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. :-)
--Kentkannan@osc.edu (Kannan Varadhan) (08/28/90)
Thus spake kwe@bu-it.bu.edu (Kent England) > 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." > > The special cases are: > > [...7 special cases...] > > I therefore conclude that a host part of zero is never a legal source address. The gentleman said earlier: : From: mf@ircam.ircam.fr (Michel Fingerhut) : Date: 25 Aug 90 22:00:42 GMT : Organization: IRCAM, Paris (France) : : Our LAN is a class B network, 129.102.0.0, and I had the unfortunate idea to : choose *legal* IP numbers for some of our main hosts of the form 129.102.nn.0, : (nn != 0). It's legal for a machine, since the HOST part, nn.0, is definitely : NOT zero. Given that he has not explicitly mentioned his subnet masks, and that he mentions that his "HOST part" is "nn.0", his <network-number> becomes 129.102, and his <host-number> becomes nn.0. On the face of it, therefore, I'd be inclined to say, he has a point. >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. :-) Aye, that it is :-) Kannan PS: I'd actually be more inclined to think that he probably subnetted his router configurations by mistake, and should very, very carefully check them up before barking up the rouing tree. -- Kannan Varadhan, Internet Engineer, OARNet Ohio Supercomputer Center, Columbus, OH 43212 +1 (614) 292-4137 email: kannan@oar.net | osu-cis!malgudi.oar.net!kannan
MAP@lcs.mit.edu (Michael A. Patton) (08/28/90)
Date: 27 Aug 90 16:32:47 GMT From: usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu (Kent England) Hi Kent, that's quite a return address you have there and you're only next door :-). 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...): A laudable ambition, but the original poster said he had consulted the RFCs and not found anything outlawing what he's doing, I don't think you did either :-). [Quotes from RFCs removed] 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. Except that you missed the point of the original poster. He is not subnetting and therefore has sixteen bits of host number. Some of his hosts are assigned (non-zero) sixteen bit numbers that happen to have all the last eight bits zero. According to all the specs this is legal. His problem comes in that some gateways (I assume not under his control) are configured to discard all packets with addresses having the low eight bits of the address zero. My reading of this would be that what he is doing is legal, and the maintainers of the intervening routers are doing something wrong. But to follow the "Be conservative in what you send, liberal in what you accept" policy would suggest not using such host addresses even though they should be valid. That's what we do here. __ /| /| /| \ Michael A. Patton, Network Manager / | / | /_|__/ Laboratory for Computer Science / |/ |/ |atton Massachusetts Institute of Technology Disclaimer: The opinions expressed above are a figment of the phosphor on your screen and do not represent the views of MIT, LCS, or MAP. :-)
mrf@FTP.COM (08/28/90)
The fact that has been overlooked in your reading of the Host Requirements RFC (which I agree is wonderful) is which portions of an IP address are which. On a Class B network (the kind in question) which is not subnetted, the last TWO (2) bytes of the address are the host format. NN.NN.HH.HH } 2 bytes of net and 2 of host. If this address is 129.126.52.0, the net portion is 129.126 and the host portion is 52.0 (or 3400 hex) which is in fact non-zero. This should therefore be a legal address on the net (in theory). The broadcast address on this net would be 129.126.255.255, and the network address would be 129.126.0.0. There would be no conflict between these addresses and the host address of 129.126.52.0. However, I am not surprised that this is rejected by several implementations, and do not think that this would be advisable on a class B network, because I do not think it would lend itself to later subnetting. The best thing for this person to do is to probably only use the 2nd host byte (unless he will have over 254 machines) and leave the first byte 0. This will allow him to less painfully put in subnetting later if necessary. Or, decide now on what his eventual network needs will be and start off with the correct values in place for subnetting (i.e give every host in one building a host value of 1.nn, another building or floor 2.nn, etc.). This might also help when network problems arise to make it easier to locate the failing machine (just a suggestion). Just because something is legal doesn't mean it works (and vice versa). Margaret Forsythe, Technical Support Manager, FTP Software, Inc. mrf@ftp.com (617) 246-0900 x100 FAX: (617) 246-0901
mf@ircam.ircam.fr (Michel Fingerhut) (08/28/90)
Michael Patton indeed explains much better than I did what I intended to say... We are NOT subnetting, the gateway filtering us out is at ANOTHER site, out of (my) control. Michael Fingerhut
kwe@bu-it.bu.edu (Kent England) (08/29/90)
In article <1990Aug28.074951.21126@ircam.ircam.fr>, mf@ircam.ircam.fr (Michel Fingerhut) writes: > Michael Patton indeed explains much better than I did what I intended to say... > We are NOT subnetting, the gateway filtering us out is at ANOTHER site, out of > (my) control. > > Michael Fingerhut Mike's pretty good at that. I was wrong to assume anything about subnetting since you didn't say anything about using subnets. As others pointed out, those addresses would cause legal problems if you ever were to subnet, but that is beside the point. It does beg the question of how you avoid this problem with arbitrary subnet length changes. That can wait for more experience with variable subnet routing protocols. :-) It did occur to me that if a router were configured with subnetting assumed (as others pointed out), then the router would probably need to take precedence over the host's idea of subnetting (assuming the class B were really subnetted), so in the long run, particularly for those who are planning migrations from bridged to routed environments, these sorts of addresses are to be avoided. (Beside your point again, I know.) From the above, I get the impression that the router that is doing the filtering is not part of your class B and, therefore, should not have any idea of your subnetting or not. I would be interested to find out more about the source of this behaviour. Is it a bug, or is the router vendor addressing some other issue? --Kent
medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (08/29/90)
However, the network wide broadcast addresses will always be broadcasts and grounds for potential filtering. Something like 128.102.255.255 will always be a broadcast no matter what subnet scheme is in use, unless you are doing something really weird(!)... Packets to this address should NEVER be forwarded... Thanks, Milo
dls@mentor.cc.purdue.edu (David L Stevens) (08/29/90)
A point of clarification, since several people have sent me e-mail on the topic... When I say "shouldn't" regarding filtering, I mean in the RFC-speak sense of "it's a bad idea." I don't mean it's contrary to any RFC, so you don't need to point out to me that some say it's fine for gateways to filter broadcast packets. Beyond that, there is the fact that it is impossible to do it right in the case we were talking about, and THAT is just plain wrong. A gateway that isn't directly attached or administered by the same people as an arbitrary IP address CANNOT answer the question "is this a broadcast?" so it doesn't matter whether an RFC says you can or not; in practice, you can't. Here's why: suppose you're a gateway and you don't have anything to do with the network 128.210 and you get a datagram with either source or destination as, say, "128.210.1.127". Is that a broadcast packet or not? Well, if my subnet mask is 255.255.255.128, the host part is all 1's and it's a broadcast. If my subnet mask is 255.255.255.0, it's a host. The remote gateway can't know what the mask is. "But WAIT!" you say. "What about an ICMP mask request??" The question, then, is, to where do you send such a mask request? Well, the only address on that net (in general) you know is 128.210.1.127, so that's you're only choice. But if it's a host, it won't (in general) answer, because only gateways are required to answer mask requests [rfc 950; 1122 says some hosts may not reply]. And, of course, if you don't get an answer, it doesn't mean it's a host-- maybe the datagram was lost. Besides, you'd be committing the sin you're trying to prevent-- sending a directed broadcast. And then, would you keep this around or send a mask request for every routed packet-- just completely impractical. So, even though RFC's say you can filter broadcast packets, the case in point doesn't allow it on the grounds that you cannot compute "is this a broadcast?" and it is clearly wrong for the router to drop the packet. "Wrong" in the sense that it inhibits legitimate use of the Internet. We have a clear demonstration of that. Philosophically, it's wrong because it flattens the hierarchical address space by requiring the internal structure of networks to be visible to the outside world for things to work. I assert that the only machines that can have any legitimate interest in the host part of an IP address are those under the same administration as the address in question. If I want to allow a host on your net to send broadcasts on mine, who benefits by some other gateway (yours or an intervening one) filtering it?? Only my networks can suffer from the broadcasting and if I don't filter it, nobody should... -- +-DLS (dls@mentor.cc.purdue.edu)
postel@VENERA.ISI.EDU (08/30/90)
Hi. I believe the following analysis by David L Stevens is correct. Some discussion like this should be added to all requirements documents and other descriptions of address filtering and/or broadcast addresses. --jon. ~~~~~~~~~ ----- Begin Included Message ----- ~~~~~~~~~~ Date: 29 Aug 90 16:31:45 GMT From: usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu (David L Stevens) Subject: Re: Hosts whose IP numbers end in 0........ Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil A point of clarification, since several people have sent me e-mail on the topic... When I say "shouldn't" regarding filtering, I mean in the RFC-speak sense of "it's a bad idea." I don't mean it's contrary to any RFC, so you don't need to point out to me that some say it's fine for gateways to filter broadcast packets. Beyond that, there is the fact that it is impossible to do it right in the case we were talking about, and THAT is just plain wrong. A gateway that isn't directly attached or administered by the same people as an arbitrary IP address CANNOT answer the question "is this a broadcast?" so it doesn't matter whether an RFC says you can or not; in practice, you can't. Here's why: suppose you're a gateway and you don't have anything to do with the network 128.210 and you get a datagram with either source or destination as, say, "128.210.1.127". Is that a broadcast packet or not? Well, if my subnet mask is 255.255.255.128, the host part is all 1's and it's a broadcast. If my subnet mask is 255.255.255.0, it's a host. The remote gateway can't know what the mask is. "But WAIT!" you say. "What about an ICMP mask request??" The question, then, is, to where do you send such a mask request? Well, the only address on that net (in general) you know is 128.210.1.127, so that's you're only choice. But if it's a host, it won't (in general) answer, because only gateways are required to answer mask requests [rfc 950; 1122 says some hosts may not reply]. And, of course, if you don't get an answer, it doesn't mean it's a host-- maybe the datagram was lost. Besides, you'd be committing the sin you're trying to prevent-- sending a directed broadcast. And then, would you keep this around or send a mask request for every routed packet-- just completely impractical. So, even though RFC's say you can filter broadcast packets, the case in point doesn't allow it on the grounds that you cannot compute "is this a broadcast?" and it is clearly wrong for the router to drop the packet. "Wrong" in the sense that it inhibits legitimate use of the Internet. We have a clear demonstration of that. Philosophically, it's wrong because it flattens the hierarchical address space by requiring the internal structure of networks to be visible to the outside world for things to work. I assert that the only machines that can have any legitimate interest in the host part of an IP address are those under the same administration as the address in question. If I want to allow a host on your net to send broadcasts on mine, who benefits by some other gateway (yours or an intervening one) filtering it?? Only my networks can suffer from the broadcasting and if I don't filter it, nobody should... -- +-DLS (dls@mentor.cc.purdue.edu) ~~~~~~~~~ ----- End Included Message ----- ~~~~~~~~~~
tmallory@BBN.COM (08/31/90)
> However, the network wide broadcast addresses will always be broadcasts > and grounds for potential filtering. Something like 128.102.255.255 will > always be a broadcast no matter what subnet scheme is in use, unless > you are doing something really weird(!)... Packets to this address should > NEVER be forwarded... If YOUR router(no interface on 128.89.0.0) ALWAYS filters 128.89.255.255 before MY router sees it, I will have to look elsewhere for transit service. ALL bits in the host part of the address must be considered to have only local significance. The fact that 128.89.255.255 must be recognized as the broadcast address by all hosts(and routers) on my network allows for interoperability on my network. It's nobody else's business. Packets to this address MUST never be forwarded when received from an interface on this network, and MAY never be forwarded to this network if I choose to have them filtered. After all that, if this flies in the face of router requirements specified beyond rfc1009, my apologies. It doesn't seem right that all one's in the host field(or all 0's for that matter), is grounds for always filterring packets to someone else's network. I probably can accept filtering packets whose source address is a broadcast address, but I'd prefer that to also be a local issue. (Hardware broadcast addresses, on the other hand, need the absolute filtering we've been talking about.) Tracy
braden@VENERA.ISI.EDU (08/31/90)
From @jessica.stanford.edu:postel@venera.isi.edu Wed Aug 29 18:16:23 1990 Date: Wed, 29 Aug 90 18:12:35 PDT From: postel@ISI.EDU To: ietf-hosts@nnsc.nsf.net, ietf-rreq@jessica.stanford.edu, tcp-ip@nic.ddn.mil Subject: Hosts whose IP numbers end in 0... Cc: postel@ISI.EDU Hi. I believe the following analysis by David L Stevens is correct. Some discussion like this should be added to all requirements documents and other descriptions of address filtering and/or broadcast addresses. --jon. ~~~~~~~~~ ----- Begin Included Message ----- ~~~~~~~~~~ Date: 29 Aug 90 16:31:45 GMT From: usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu (David L Stevens) Subject: Re: Hosts whose IP numbers end in 0........ Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil A point of clarification, since several people have sent me e-mail on the topic... When I say "shouldn't" regarding filtering, I mean in the RFC-speak sense of "it's a bad idea." I don't mean it's contrary to any RFC, so you don't need to point out to me that some say it's fine for gateways to filter broadcast packets. Beyond that, there is the fact that it is impossible to do it right in the case we were talking about, and THAT is just plain wrong. A gateway that isn't directly attached or administered by the same people as an arbitrary IP address CANNOT answer the question "is this a broadcast?" so it doesn't matter whether an RFC says you can or not; in practice, you can't. Jon and David, Sorry, I think there is a confusion here. Filtering out directed broadcasts is neither a "bad idea" nor "impossible"!! This means: those broadcasts that the given gateway can legally and possibly detect. Of course, it does NOT mean breaking the rules about invisibility of subnets outside a subnetted network, and it does NOT mean making illegal assumptions about byte boundaries within subfields of the IP address. Jon thinks David and I are having an agreement, but I am unclear about that. Bob Braden
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (09/05/90)
Bob, Jon, et al.--
In the spirit of "Sometimes it's necessary to make sure everybody means the
same thing even by 'NO-OP'", I suspect it's past time for me to observe that
the problem with the Subject "thread" is that some of the discussants seem
to be making rather different unstated assumptions about "filtering" than
others are.
I THINK the original question had to do with what we might call "outgoing
filtering", in the sense of rejection of datagrams by gateways other than
the gateway which is connected to the/a communications subnetwork (NOT "subnet"
in the current jargon sense of the term) to which the destination Host is
attached, which is the only gateway that could "know" whether the proferred
address would lead to a broadcast. Yet several of the responses SEEM to be
taking the point of view of just that "terminal" gateway and holding that
of course it's entitled to "filter". My own impression is that it's precisely
this latter, "incoming filtering", case in which "judgement" might/can/should
be exercised by a gateway, and only this latter, incoming filtering case.
But irrespective of whether that's the "correct" view, I do think that the
thread will remain tangled until and unless we start explicitly distinguishing
between "outgoing" and "incoming" "filtering"--the failure to do which
EXPLICITLY I did mentally note, and regret not commenting upon, when the
message Jon subsequently endorsed went by, b/t/w, thinking I'd probably just
skimmed over it too quickly and assuming the issue would eventually be
resolved without my having to make a religious (= Semantic Puritanism)
issue of it.
However, now that we've got the co-authors of the Requirements RFC in
apparent disagreement, it does seem desirable to confirm that they aren't
just re-enacting the old baddie about the neighbors who could never agree
because they were arguing from different premises....
Semantically Puritanical cheers,
map
-------dls@mentor.cc.purdue.edu (David L Stevens) (09/06/90)
I think Michael Padlipsky's analysis hit the hammer on the nose, is right on the nail, or whatever mixed metaphor you like... :-) My arguments assume "gateway not attached or administered by the same people who do the network on whose address the filtered address lives." In other words, as I said, take the DLS challenge: if you can't answer the question "Is 128.210.50.127 a host or a broadcast address?" you have no business filtering it out on the grounds that it's a broadcast. The most unfortunate part is that I think many naive gateway administrators will presume more than they should and will answer the question "sure, I can tell" when they really can't. So my opinion, beyond any RFC arguments, and which I don't expect or even want to become "law," is that filtering, except in very carefully considered cases, just shouldn't be done at all. You see, if it's done wrong, it affects people well outside those that can have it changed and, worse, the primary benefits only affect those behind the net, anyway. If some non-128.210 gateway is filtering broadcasts, what I say is "don't be nice to me-- if I don't want to see them, *I'll* filter them." The broadcast happens, after all, on my nets. Now, certainly, if there are generated replies from all of my hosts to the source of this broadcast, the remote guy and all the intervening gateways have a problem too. But should we accept loss of legitimate connectivity as a sacrifice for doing the wrong thing it what should be relatively infrequent, anomalous cases? Most protocols know already whether receiving on a broadcast address is legitimate or not, anyway, so I think the gain, as far filtering broadcasts in particular, is absolutely minimal for anyone outside the network of the filtered address. -- +-DLS (dls@mentor.cc.purdue.edu)