I agree with RS.  A /16 is a drop in the bucket and we shouldn't waste time worrying about it.<div>Stacy<br><div><br><div class="gmail_quote">On Tue, Sep 22, 2009 at 12:48 PM, Robert E. Seastrom <span dir="ltr"><<a href="mailto:rs@seastrom.com">rs@seastrom.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> writes:<br>
<br>
> I think that now is NOT the time to be expanding the wasted IPv4<br>
> address space.  This block should be documented for it's prior<br>
> misuse in examples.  That use should be deprecated, and, the block<br>
> should be placed in the free pool.<br>
<br>
</div>I respectfully disagree.  That sounds like a great idea right up until<br>
*your* organization becomes the lucky folks who get assigned it, and<br>
given this sentiment:<br>
<div class="im"><br>
> I would not object to placing it low on the priority list of blocks<br>
> to be issued, but, that's 65,536 IPs that should not be left fallow<br>
<br>
</div>there will likely be a dearth of spare addresses left to renumber into<br>
if you decide you can't deal and try to swap out the block with ARIN.<br>
<div class="im"><br>
> simply due to prior misuse.<br>
<br>
</div>There was no misuse here.  The name NET-TEST-B suggests that using it<br>
for examples is perfectly reasonable (and perhaps even using it for<br>
"testing", perish the thought!).<br>
<br>
The question boils down to "will adding 2^16 addresses to the free<br>
pool be worth the heartburn that will result from using an address<br>
block that is so-tainted and appears in a lot of filters?"<br>
<br>
I submit that it is not.  At a burn rate of 14 /8s per year, that's<br>
roughly a /8 every 26 days.  Reclaiming <a href="http://128.66.0.0/16" target="_blank">128.66.0.0/16</a> to the free pool<br>
will stave off free pool exhaustion by roughly 8800 seconds, not even<br>
three hours.<br>
<br>
If we were looking at a /8, my thoughts might be a bit different.  My<br>
gut feeling is that chasing /8s out of static bogon filters is a lot<br>
less difficult than chasing /16s out of the same - more space for<br>
servers to land that people care about...  and we all know what a pain<br>
it is even for a /8.  I am in favor of continuing to mark this block<br>
as reserved due to its previous use.<br>
<br>
Now, that said, there are addresses that well and truly don't matter<br>
in terms of the ability to aspire to global reachability - router<br>
loopbacks for instance.  I'm A-OK with the notion that if the<br>
assignment could be restricted to recipients who have indicated that<br>
this constraint is fine, we could do that.  Harsh reality intrudes,<br>
though, and inasmuch as I don't think there is a mechanism in place at<br>
any RIR for pulling this off, I'd say the better part of responsible<br>
stewardship is to hold these addresses as reserved rather than handing<br>
out known-more-defective-than-usual product.<br>
<font color="#888888"><br>
-r<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
ARIN-Discuss<br>
You are receiving this message because you are subscribed to<br>
the ARIN Discussion Mailing List (<a href="mailto:ARIN-discuss@arin.net">ARIN-discuss@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-discuss" target="_blank">http://lists.arin.net/mailman/listinfo/arin-discuss</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br></div></div>