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

[Stacy Hughes]

I agree with RS.  A /16 is a drop in the bucket and we shouldn't waste time
worrying about it.Stacy

On Tue, Sep 22, 2009 at 12:48 PM, Robert E. Seastrom <rs at seastrom.com>wrote:

>
> 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
>
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to
> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20090922/62472427/attachment.html>