Hello all,
As a general rule, is it best practice to assign x.x.x.0 and x.x.x.255 as host addresses on /23 and larger? I realize that technically they are valid addresses, but does anyone assign a node or server which is a member of a /22 with a x.x.x.0 and x.x.x.255? Is it just a manner of preference on whether or not to use them, or are there functional reasons you shouldn’t; either with rfc 1918 addresses or public addresses.
Thanks in advance,
J
I like to use them for critical service machines, since many versions of Windows will not send packets to them, so they are protected from most (but not all!) botnets.
Hello all,
As a general rule, is it best practice to assign x.x.x.0 and
x.x.x.255 as host addresses on /23 and larger?
Yes. Efficient address utilization is a Good Thing.
I realize that technically they are valid addresses, but does anyone
assign a node or server which is a member of a /22 with a x.x.x.0
and x.x.x.255?
Great for router interfaces, loops, etc where you don't care that
broken or archaic systems cannot reach them, and where the humans
interacting with them should have no issues.
Cheers,
Joe
Until you assign a .255/32 to a router loopback interface and then find that you can't get to it because some silly router between you and it thinks '.255? that's a broadcast address.'
Been there...had to change the loopback IP.
See the qualifier "where you don't care that broken or archaic systems
cannot reach them". If you have brokenness on your internal systems
then yes, you'd be shooting yourself in the foot.
Until you shoot yourself in the foot, how would you know you have such brokenness on your internal systems? That silly router happened to be a 7206 running (IIRC) 12.1T code.
Unless you really don't care about the brokenness, or really want to root it all out, I'd avoid using .0 and .255 IPs.
Jon Lewis <jlewis@lewis.org> writes:
Until you assign a .255/32 to a router loopback interface and then find
that you can't get to it because some silly router between you and it
thinks '.255? that's a broadcast address.'See the qualifier "where you don't care that broken or archaic systems
cannot reach them". If you have brokenness on your internal systems
then yes, you'd be shooting yourself in the foot.Until you shoot yourself in the foot, how would you know you have such
brokenness on your internal systems? That silly router happened to be
a 7206 running (IIRC) 12.1T code.Unless you really don't care about the brokenness, or really want to
root it all out, I'd avoid using .0 and .255 IPs.
At Inter.Net, we specifically excluded .0 and .255 from our DSL pools
so as to not screw up the day of people running outdated Windows
software any more than it was already screwed up. At some point you
have to weigh the relative costs of 0.78% waste in IP address space
vs. technician time to troubleshoot the lossage. With due respect to
jzp, I'll err on the side of saving myself the bucks.
---Rob
At Inter.Net, we specifically excluded .0 and .255 from our DSL pools
so as to not screw up the day of people running outdated Windows
software any more than it was already screwed up.
According to Microsoft KB 281507
http://support.microsoft.com/default.aspx?scid=kb;en-us;281579
even "XP Home" and "Server 2003 Standard" are affected.
Could anyone share some pointers to test results or any other listing of
broken and correct IP stacks regarding this issue?
Andras
Historically, .0 and .255 have been avoided because a lot of servers
(windows) wouldn't work using that as a host address or would flag it
as invalid if you tried to connect to it or a myriad of other
problems. Note that this was a limitation of the host, not anything to
do with the network or any of the network equipment.
This issue has not existed with any prevelance for quite some time and
almost everything of recent manufacture is quite happy to be assigned
in a supernet as well as on the .0 and .255 addresses.
So my oppinion is don't hesistate to use it until you find a real,
reproducible problem.
-Wayne
"Wayne E. Bouchard" <web@typo.org> writes:
So my oppinion is don't hesistate to use it until you find a real,
reproducible problem.
Tell that to your call center manager. 
---rob
Historically, .0 and .255 have been avoided because a lot of servers
(windows) wouldn't work using that as a host address or would flag it
as invalid if you tried to connect to it or a myriad of other
problems. Note that this was a limitation of the host, not anything to
do with the network or any of the network equipment.This issue has not existed with any prevelance for quite some time and
almost everything of recent manufacture is quite happy to be assigned
in a supernet as well as on the .0 and .255 addresses.So my oppinion is don't hesistate to use it until you find a real,
reproducible problem.-Wayne
I have seen networks where traffic to these addresses was filtered in an
attempt to mitigate broadcast address amplification. Typically, end users
filter their inbound Internet traffic to their own addresses. They know they
don't use .0 or .255 addresses and they found this is a quick way to prevent
any nodes on their internal network from being used as amplifiers without
having to audit/fix their entire internal network.
As we know, the "workaround" may remain in their edge router(s) long after
it has outlived its usefulness.
A few years ago, I noticed that an ISP blocked all traffic from its
customers bound for any .0 or .255 address to prevent drones from flooding
those addresses. I doubt this is typical, but I bet it's still around in at
least a few places.
If you're seriously considering using these addresses, these are other
possible issue you need to consider.
DS
I am astounded at seeing this discussion. I have not seen this much disavowing of CIDR addressing since 2003 or before.
At least these arguments against .0 and .255 IPv4 addresses are based on perceived cost of operations, not ignorance of effective network number vs effective host number. Now, if we can get Microsoft to really support TCP/IP, we can make much progress. Of course, ubiquitous deployment of IPv6 will fix all that.
Especially on proxied enterprise networks, use all the addresses available base on the effective network address having host number of 0 and the broadcast address being an effective host address of all ones. We have had much success with this approach for some large customer networks. Also, if your router OS works in a classful manner, tell the vendor to fix it. We got CIDR years and years ago.
Note, the referenced Microsoft article uses the phrase, "the client may have difficulty communicating", not will.
"James R. Cutler" <james.cutler@consultant.com> writes:
I am astounded at seeing this discussion. I have not seen this much
disavowing of CIDR addressing since 2003 or before.
To steal a phrase from Dave Rand, "you're confused". Nobody is
disavowing CIDR, nor is anyone arguing against using the all-zeroes or
all-ones addresses out of a block of any size other than a /8, a /16,
or a /24. We're saying "last octet should not be .0 or .255 because
it is possible to have it bite you, and the costs of not using those
addresses is pretty low" (see model below).
At least these arguments against .0 and .255 IPv4 addresses are based
on perceived cost of operations, not ignorance of effective network
number vs effective host number.
Not just perceived, actual (as in "we tried this, promptly got a weird
failure escalated to us from the call center").
Now, if we can get Microsoft to
really support TCP/IP, we can make much progress.
Fifteen years later, perhaps. There are still folks out there running
Windows 98SE, and believe you me, they are the LAST people that you
want to be on the other end of the phone line when your call center
employee is trying to talk them through simple debugging. Microsoft
could fix everything tomorrow on all platforms and you still have to
deal with people who don't patch and people who are just running out
the lifetime on their hardware.
Of course,
ubiquitous deployment of IPv6 will fix all that.
See above. Adjust time frame based on the amount of cheerful optimism
you feel.
Especially on proxied enterprise networks, use all the addresses
available base on the effective network address having host number of
0 and the broadcast address being an effective host address of all
ones.
Unless you are speaking of a proxied enterprise network that has a /24
or larger of space in the proxy pool, this is a meaningless statement.
And if you are, the union of { enterprise customers } and { joe and
jane ludd with their 98OSR2 box } is likely { }. [*]
We have had much success with this approach for some large
customer networks. Also, if your router OS works in a classful
manner, tell the vendor to fix it. We got CIDR years and years ago.
We got TCO years and years ago. Let's do the math here. Suppose that
you are a "medium size" ISP in the ARIN region with a total allocation
that adds up to a /16. From looking at
http://www.arin.net/billing/fee_schedule.html#ipv4_alloc we know that
you're paying $4500/year in fees. Now, this space is divided up
thusly: 1/4 for hosting, 1/4 for dial customers, and 1/2 for DSL
customers. In the dial and DSL arenas, you have 192 /24s in your
pools. That means you're going to declare 384 addresses (the 0s and
1s) off limits out of 65536 assigned to you, or 0.58%. This
represents a cost of $2.61 per annum for the address space that is out
of play.
Exercise for the reader: Assuming a fully loaded cost of help desk
personnel (including insurance, employer side social security tax,
office space, IT support, electricity, etc) of $30/hour (cheap!), how
many 10 minute support calls can you take per year before you're
behind, assuming that your inexpensive $30/hour tech is able to figure
out the problem without escalation, which is probably pretty optimistic.
Looking at this from a "wasted IP address space guilt" perspective,
the waste is exactly as much as if you had deployed /24 subnets in a
hosting center on ethernet, where you'd not be using the 0s and 1s
anyway. Odds are that you'd be using subnets a lot smaller than this,
and "wasting" substantially more addresses.
The only downside is that you end up with some ugly looking pool
declarations, something along the lines of:
ip local pool ar00-yul1-dynamic 10.4.56.1 10.4.56.254
ip local pool ar00-yul1-dynamic 10.4.57.1 10.4.57.254
ip local pool ar00-yul1-dynamic 10.4.58.1 10.4.58.254
ip local pool ar00-yul1-dynamic 10.4.59.1 10.4.59.254
ip local pool ar00-yul1-dynamic 10.4.60.1 10.4.60.254
ip local pool ar00-yul1-dynamic 10.4.61.1 10.4.61.254
ip local pool ar00-yul1-dynamic 10.4.62.1 10.4.62.254
ip local pool ar00-yul1-dynamic 10.4.63.1 10.4.63.191
(globally unique addresses from the original example redacted, natch)
Note, the referenced Microsoft article uses the phrase, "the client
may have difficulty communicating", not will.
To paraphrase another of our illustrious colleagues, "I encourage my
competitors to do this".
---Rob
[*] Our experience was that 98 was pretty sure to be affected;
obviously being behind a firewall helps enormously and most people are
these days, but most people are not '98 users, and the observation
about the relative costs involved remains correct. In the case where
I was consulting to a small ISP in the ARIN region with a /20 (15 of
the 16 /24s used for DSL), the costs were 30 addresses out of play out
of a pool of 4096 which cost us $2250/year, or a total IP address cost
of $16.47; plug into above TCO model.