I remember back in the day of old hardware and operating
systems we'd intentionally avoid using .255 IP addresses
for anything even when the netmask on our side would have
made it fine, so I just thought I'd try it out for kicks
today. From two of four ISP's it worked fine, from Verizon
FIOS and Road Runner commercial, it didn't. So I guess
that old problem still lingers?
David
RFC1519 is 15 years old now. I *still* heard a trainer (in a Cisco
class no less) mention class A/B/C in the last few months. Some evil
will obviously take generations to fully stamp out.
Anybody from Verizon FIOS or RoadRunner care to explain why David is seeing
an issue in 2008?
not from either, and hopefully david will follow back up with some of
his findings, but.. I'd bet dollars to donuts it's the ultra-crappy
CPE both vendors ship 
go-go-actiontec (vol sends those out, god do they suck...)
-Chris
Or leftover filters from before 'no ip directed-broadcast'
in the days of Smurf attacks.
-Dave
Christopher Morrow wrote:
go-go-actiontec (vol sends those out, god do they suck...)
Crappy CPE's are exactly why we don't hand out .0 and .255 addresses in our DHCP pools. 
I have had a look into the manuals of my ISP's routers.
Those boxes can think in /24 only. The split whatever you
have down to several /24 and reserve both .0 and .255 in
each of them.
I have seen both .0 and .255 in the WLAN behind NAT working
but you have to ifconfig the interface via telnet. The
html configuration wont allow to do it.
Kind regards
Peter
David Andersen wrote:
David Hubbard wrote:
I remember back in the day of old hardware and operating
systems we'd intentionally avoid using .255 IP addresses
for anything even when the netmask on our side would have
made it fine, so I just thought I'd try it out for kicks
today. From two of four ISP's it worked fine, from Verizon
FIOS and Road Runner commercial, it didn't. So I guess
that old problem still lingers?
The TCP/IP stack in Windows XP is broken in this regard, possibly in Vista as well, though I've yet to have the displeasure of finding out. I have a router with a .255 loopback IP on it. My Windows XP hosts cannot SSH to it. The specific error that Putty throws is "Network error: Cannot assign requested address".
At least if I ever need to completely protect a device from access by Windows users, I have a good option 
Mike
Mike Lewinski wrote:
The TCP/IP stack in Windows XP is broken in this regard, possibly in Vista as well, though I've yet to have the displeasure of finding out.
A co-worker confirms that his Vista SP1 can access our .255 router via SSH.
Mike Lewinski wrote:
The TCP/IP stack in Windows XP is broken in this regard, possibly in Vista as well, though I've yet to have the displeasure of finding out.
A co-worker confirms that his Vista SP1 can access our .255 router via SSH.
Aww, that's too bad. I've long enjoyed setting loopback and other internal
device addresses to .255 -- it drastically reduced some attacks, and made
security by obscurity work better.
Not that I recommend obscurity as the only security. 
Mike Lewinski wrote:
David Hubbard wrote:
I remember back in the day of old hardware and operating
systems we'd intentionally avoid using .255 IP addresses
for anything even when the netmask on our side would have
made it fine, so I just thought I'd try it out for kicks
today. From two of four ISP's it worked fine, from Verizon
FIOS and Road Runner commercial, it didn't. So I guess
that old problem still lingers?The TCP/IP stack in Windows XP is broken in this regard, possibly in Vista as well, though I've yet to have the displeasure of finding out. I have a router with a .255 loopback IP on it. My Windows XP hosts cannot SSH to it. The specific error that Putty throws is "Network error: Cannot assign requested address".
At least if I ever need to completely protect a device from access by Windows users, I have a good option
Mike
We had to split our assigned ranges (PPP/PPPoE) into /24, even if it were assigned to the (NAS, BRAS, etc) in larger chunks. It seems customers who were assigned the .0/.255 could get out there - but certain sites (IIS it seemed) would refuse to talk back.
I forget if I tested microsoft.com like this...
We avoid them because in the interest of "security", customers who
would be assigned .0 and .255 have trouble accessing their online
banking and other financial websites. With IPv4 address space running
out, we'll probably inevitably have to start handing them out and then
get our customers to complain to their bank etc.
Regards,
Mark.
Funny this discussion surfaced now - I got bitten by this recently.
Was using .255 for NAT on a secondary firewall. When the primary
failed over, parts of the Internet became unreachable...
Tim:>
We've faced two issues with .255 and .0:
- Using /31 links Windows tracert * * *'s on .0 addresses. Had many users who thought they knew better complain about it.
- Using a .255 loopback on a Cisco 6500 SNMP requests would return from the closest interface IP address. Combined with a specific version of SNMP libraries (which I can't recall right now), this caused queries to fail.
Rgds,
- I.
Ian Henderson wrote:
- Using a .255 loopback on a Cisco 6500 SNMP requests would return from the closest interface IP address. Combined with a specific version of SNMP libraries (which I can't recall right now), this caused queries to fail
I had a weird Cisco problem on 12.2S where it would refuse to establish a BGP peering to a loopback with a .0 IP address. I moved it to something else and it worked fine. I gave up trying to figure it out.
David
well... .0 and .255 are still special in -some- contexts.
they still form the all-zeros and all-ones broadcast addresses
for the defined block... so:
192.168.16.0/23
192.168.16.0/32 is unusable
192.168.16.255/32 is useable
192.168.17.0/32 is useable
192.168.17.255/32 is unuseable.
crapy CPE, vendor instruction, poor software all contribute
to VLSM being poorly understood and these "gotchas" still
around - years - later.
my recommendation... place your caching nameservers and webservers on
these addresses... if you want to force the issue. 
--bill
* Valdis Kletnieks:
RFC1519 is 15 years old now. I *still* heard a trainer (in a Cisco
class no less) mention class A/B/C in the last few months. Some evil
will obviously take generations to fully stamp out.
You need to know something about classes when you deal with Cisco gear
because IOS strips prefix lengths on output if they match the length
implied by the class.
From what I recall, Microsoft's stack was based on the only free one they could afford back in the Trumpet/Winsock days, namely BSD's.
It is either dependent on how the stack is integrated, or it simply implies that BSD's stack is(was) also broken (I'd tend to doubt that).
Also, Vista's stack was supposed to have been re-developed from scratch, never checked it.
Greg VILLAIN