North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: [nsp] known networks for broadcast ping attacks
- From: Joe Provo - Network Architect
- Date: Sat Aug 02 23:55:08 1997
>On Wed, Jul 30, 1997 at 10:15:24PM -0700, Joe Rhett wrote:
>> > .255 is _always_ a broadcast address, no?
>> Uh, no. If the bit mask is smaller than /24, any given .255 address could
>> be legitimate.
>RFC 917 and RFC 922 (admittedly old) suggest strongly that this isn't a
>good idea; I'm still searching to find the reference I remember that
>specifically deprecates it.
This isn't a problem, nor is it recent/CIDR-specific. Given a /16
('class B') that everyone and their brother had not even 5 years ago
and a flat network, X.Y.n.255 isn't only a valid address for all values
of "n", but is in real live use today. The only reason it wouldn't be
"a good idea" is because we network folks have to be able to react and
change things as needed, and there's less pain in skipping a few
addresses so you stay on the "clean" bit boundaries then painting
yourself into a corner WRT possible future subnetting and needing to
renumber folks. I would say also because "vendors can be counted on to
make nasty assumptions", but I can't think of any off the top of my
head that, given the right address/mask pair, would make the wrong
assumption (except those known to err in favour of being classful).
>I guess it matters, since I'm not aware of routers that allow the
>specification of filter rule addresses with /netsizes.
I don't follow the significance of your statrement. There's no true
difference between specifying masks by noting the bitsize or writing out
the actual masks in octets; consider the former "reasonable-to-humans
shorthand" and the latter akin to long division. Aside from that, it's
an IP world, where specific implementation is meaningless... but off
the top of my head, Compatible Systems boxes us /xx notation in their
Joe Provo, Network Architect 800.763.8111 x3006
Network Operations Center Fax 508.229.2375
UltraNet Communications, Inc. <email@example.com>