[arin-discuss] use of 128.66.0.0/16 not clear

[Robert E. Seastrom]

Owen DeLong <owen at delong.com> writes:

> I think that now is NOT the time to be expanding the wasted IPv4
> address space.  This block should be documented for it's prior
> misuse in examples.  That use should be deprecated, and, the block
> should be placed in the free pool.

I respectfully disagree.  That sounds like a great idea right up until
*your* organization becomes the lucky folks who get assigned it, and
given this sentiment:

> I would not object to placing it low on the priority list of blocks
> to be issued, but, that's 65,536 IPs that should not be left fallow

there will likely be a dearth of spare addresses left to renumber into
if you decide you can't deal and try to swap out the block with ARIN.

> simply due to prior misuse.

There was no misuse here.  The name NET-TEST-B suggests that using it
for examples is perfectly reasonable (and perhaps even using it for
"testing", perish the thought!).

The question boils down to "will adding 2^16 addresses to the free
pool be worth the heartburn that will result from using an address
block that is so-tainted and appears in a lot of filters?"

I submit that it is not.  At a burn rate of 14 /8s per year, that's
roughly a /8 every 26 days.  Reclaiming 128.66.0.0/16 to the free pool
will stave off free pool exhaustion by roughly 8800 seconds, not even
three hours.

If we were looking at a /8, my thoughts might be a bit different.  My
gut feeling is that chasing /8s out of static bogon filters is a lot
less difficult than chasing /16s out of the same - more space for
servers to land that people care about...  and we all know what a pain
it is even for a /8.  I am in favor of continuing to mark this block
as reserved due to its previous use.

Now, that said, there are addresses that well and truly don't matter
in terms of the ability to aspire to global reachability - router
loopbacks for instance.  I'm A-OK with the notion that if the
assignment could be restricted to recipients who have indicated that
this constraint is fine, we could do that.  Harsh reality intrudes,
though, and inasmuch as I don't think there is a mechanism in place at
any RIR for pulling this off, I'd say the better part of responsible
stewardship is to hold these addresses as reserved rather than handing
out known-more-defective-than-usual product.

-r