I see traffic from this last IP address octet all the time from prefixes of length less than /24. Use of these host id's when the prefix length is greater than or equal to /24 is illegal. So if that's your case, I'd suggest not doing it. If that's not the case, look for over-zealous or incorrect filters in the path. I saw this situation once before. There was a border ingress filter with a typo in it... Chris
Various people I've asked about this have said they wouldn't use the .0 or .255 addresses themselves, though couldn't present any concrete info about why not; my experience above would seem to suggest a reason not to use them.
On Sat, Jun 26, 2004 at 07:41:17PM -0400, Chris Ranch wrote:
I see traffic from this last IP address octet all the time from prefixes of length less than /24. Use of these host id's when the prefix length is greater than or equal to /24 is illegal. So if that's your case, I'd suggest not doing it.
It's from a /24 assignment, but is actually being used for tunnel endpoints, so there seemed to be no reason not to use the .0 address.
If that's not the case, look for over-zealous or incorrect filters in the path. I saw this situation once before. There was a border ingress filter with a typo in it...
I spent a long time looking for each filters, and watching traffic leave our network but not receiving any replies, while traceroutes would work just fine. As Peter points out, it's from what would have been Class C space, so it looks like I'm getting bitten by the Windows stuff. All 3 sites I mentioned as not being accessible are running under Windows according to Netcraft. J. -- Revd. Jonathan McDowell, ULC | I don't know. I'm a dog.
While it is often great sport to poke at MS, did you consider that this might have nothing to do with classfullness or CIDR? I believe you will find that 0 & -1 are invalid for whatever netmask the windows stack is given. You might also find that some 'features' are mitigation for exploits that existed at one time (possibly long before some of the thread participants were in high school). The fact that other OS's support an inverted state is not necessarily a reason to change the Windows behavior. Be very aware that it is much easier to sit in judgment than it is to actually provide support for the technically clueless masses. Also be aware that exploits are targeted where they will have the most impact, so the fact that someone is not taking advantage of a niche OS is a point in time phenomena. Long before Windows shipped, the target of that period was the various flavors of Unix. Tony
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jonathan McDowell Sent: Sunday, June 27, 2004 2:45 AM To: nanog@nanog.org Subject: Re: The use of .0/.255 addresses.
On Sat, Jun 26, 2004 at 07:41:17PM -0400, Chris Ranch wrote:
I see traffic from this last IP address octet all the time from prefixes of length less than /24. Use of these host id's when the prefix length is greater than or equal to /24 is illegal. So if that's your case, I'd suggest not doing it.
It's from a /24 assignment, but is actually being used for tunnel endpoints, so there seemed to be no reason not to use the .0 address.
If that's not the case, look for over-zealous or incorrect filters in the path. I saw this situation once before. There was a border ingress filter with a typo in it...
I spent a long time looking for each filters, and watching traffic leave our network but not receiving any replies, while traceroutes would work just fine.
As Peter points out, it's from what would have been Class C space, so it looks like I'm getting bitten by the Windows stuff. All 3 sites I mentioned as not being accessible are running under Windows according to Netcraft.
J.
-- Revd. Jonathan McDowell, ULC | I don't know. I'm a dog.
On Mon, Jun 28, 2004 at 11:41:50AM -0700, Tony Hain wrote:
While it is often great sport to poke at MS, did you consider that this might have nothing to do with classfullness or CIDR? I believe you will find that 0 & -1 are invalid for whatever netmask the windows stack is given. You
So you're saying that with 10.200.200.0/22, that 10.200.201.0, 10.200.202.0 and 10.200.203.0 are invalid host addresses? Setting up DHCP scopes for this space must be painful. Not to mention use of /32 addressing for loopbacks. I could almost forgive not handling /31 given that RFC3021 was onlyu published in 12/2000. Bob
Tony Hain <alh-ietf@tndh.net> wrote:
While it is often great sport to poke at MS, did you consider that this might have nothing to do with classfullness or CIDR? I believe you will find that 0 & -1 are invalid for whatever netmask the windows stack is given.
I think you may be confused about the problem. Let's not mask the IP addresses that I spotted this problem, but get them out into the open. (BTW, don't bother probing these addresses to retrace my steps, some hosts are now down, firewalled, or roaming the aisles of Gotts Road in ghostly torment.) On the one end of the connection, we have a Windows 2000 box with the IP address 217.169.21.28 and a Linux box with the adjacent IP address 217.169.21.29. These are on a LAN with a 255.255.255.240 netmask. In classful parlance, it is a Class C that has been subnetted. I also have a packet sniffer on the network. On the other end of the connection, we have a Linux box with the IP address 195.92.249.0. I forget the exact netmask, but it was around the /19 or /20 mark. In classful parlance, it is a Class C that has been supernetted.
From the Windows box, I can ping 195.92.249.0 fine. I can't seem to ssh to that IP though. Break out the packet sniffer.
I ping, and the packet sniffer shows packets leaving, and coming back ~25ms later. Good. I fire up telnet and point it at port 22. "Connection refused". Packet sniffer shows no traffic. Double-checking from the Linux box, I can ping and telnet to port 22, and I get packets flowing just fine. By the way, the Windows 2000 box is stock install, with no service packs, "personal firewall" software, antivirus stuff, etc, etc. In other words a sitting duck :) but it does mean that the problems aren't caused by third-party software. You will note that 195.92.249.0 is not all-bits-zero or all-bits-set ("0 & -1") on 217.169.21.16/28. Therefore it is a perfectly valid IP address. Windows has *no* business interpreting IP addresses outside its limited view of the world.
You might also find that some 'features' are mitigation for exploits that existed at one time
Exactly what exploits are mitigated by blocking TCP connections, but letting ICMP through just fine? It's not as if worms can't create raw sockets and create packets (with or without the evil bit) as appropriate.
(possibly long before some of the thread participants were in high school).
I'm older than TCP/IP and the Internet. I'd left school well before Windows had heard of the Internet. Haven't got the Unix hacker beard yet though :) -- PGP key ID E85DC776 - finger abuse@mooli.org.uk for full key
On Tue, 29 Jun 2004, Peter Corlett wrote:
Tony Hain <alh-ietf@tndh.net> wrote:
While it is often great sport to poke at MS, did you consider that this might have nothing to do with classfullness or CIDR? I believe you will find that 0 & -1 are invalid for whatever netmask the windows stack is given.
I think you may be confused about the problem. Let's not mask the IP addresses that I spotted this problem, but get them out into the open. (BTW, don't bother probing these addresses to retrace my steps, some hosts are now down, firewalled, or roaming the aisles of Gotts Road in ghostly torment.)
Step back.. The windows box does not have the problem IP directly connected nor does it have it specifically in its routing table, it is also not in the same classful network as the problem IP. Therefore netmasks are not involved, therefore it should not do anything other than forward it to the default. Afaik this is true of both classful and classless networking. Steve
On the one end of the connection, we have a Windows 2000 box with the IP address 217.169.21.28 and a Linux box with the adjacent IP address 217.169.21.29. These are on a LAN with a 255.255.255.240 netmask. In classful parlance, it is a Class C that has been subnetted. I also have a packet sniffer on the network.
On the other end of the connection, we have a Linux box with the IP address 195.92.249.0. I forget the exact netmask, but it was around the /19 or /20 mark. In classful parlance, it is a Class C that has been supernetted.
From the Windows box, I can ping 195.92.249.0 fine. I can't seem to ssh to that IP though. Break out the packet sniffer.
I ping, and the packet sniffer shows packets leaving, and coming back ~25ms later. Good. I fire up telnet and point it at port 22. "Connection refused". Packet sniffer shows no traffic. Double-checking from the Linux box, I can ping and telnet to port 22, and I get packets flowing just fine.
By the way, the Windows 2000 box is stock install, with no service packs, "personal firewall" software, antivirus stuff, etc, etc. In other words a sitting duck :) but it does mean that the problems aren't caused by third-party software.
You will note that 195.92.249.0 is not all-bits-zero or all-bits-set ("0 & -1") on 217.169.21.16/28. Therefore it is a perfectly valid IP address. Windows has *no* business interpreting IP addresses outside its limited view of the world.
You might also find that some 'features' are mitigation for exploits that existed at one time
Exactly what exploits are mitigated by blocking TCP connections, but letting ICMP through just fine? It's not as if worms can't create raw sockets and create packets (with or without the evil bit) as appropriate.
(possibly long before some of the thread participants were in high school).
I'm older than TCP/IP and the Internet. I'd left school well before Windows had heard of the Internet. Haven't got the Unix hacker beard yet though :)
participants (6)
-
abuse＠cabal.org.uk -
Chris Ranch -
Jonathan McDowell -
rsnyder＠toontown.erial.nj.us -
Stephen J. Wilcox -
Tony Hain