On Tue, Jan 08, 2008 at 09:50:13AM -0500, Jon Lewis wrote:

On Tue, 8 Jan 2008, Joe Provo wrote:

...

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.

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. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

Jon Lewis <jlewis@lewis.org> writes:

On Tue, 8 Jan 2008, Joe Provo wrote:

...

...

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

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

"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.