<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 29, 2014 at 9:26 AM, ARIN <span dir="ltr"><<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 24 January 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-195 Remove 8.2 and 8.3 and 8.4 Minimum IPv4 Block Size Requirements" as a Draft Policy.<br></blockquote><div><br></div><div>I oppose prop 195 as written, because (1) it is unnecessary.</div>
<div><br></div><div>(2) This is yet another IPv4-focused policy. At this point, ARIN should be essentially looking at IPv6 policies policies only, and not make changes that could adversly further affect IPv4 runout in problematic ways.</div>
<div><br></div><div>(3) Free pools are not yet exhausted, so interest in 8.3 transfers cannot yet be regarded or observed in any terms --- let alone to show that "available /24s and longer" are inadequate,</div>
<div><br></div><div>(4) IPv6 is likely to be adopted more heavily, obviating the usefulness of any attempts to increase the number of resource transfers occuring.</div><div><br></div><div>(5) Prefixes of /24 and larger will most likely be available over specified transfer,</div>
<div>and (4) Allowing attempts to fragment /24s in IPv4 do not significantly delay exhaustion of IPv4, but instead is a potential source of a great deal of pain.</div><div> </div><div>(6)</div><div> Disagree with "allowing networks to move blocks around as they see fit". The manner "in which some networks see fit" is not necessarily a good thing for the level of global routing table bloat.</div>
<div><br></div><div>(7)</div><div>A problem is: as long as routes for these prefixes would hypothetically be accepted,</div><div>the networks who "see fit to move smaller blocks around and fragment /24s into small chunks to sell off IP by IP" are not bearing the cost of their actions --- other ARIN members would be essentially forced to bear costs.</div>
<div><br></div><div>Ultimately resulting in greater unpredictability, whether a prefix received by allocation or transfer could successfully be routed globally.</div><div> </div><div>Lack of a minimum would potentially see some networks splitting off large numbers of "surplus" /25 or /26 prefixes, and some small networks accreting 3 or 4 of these transfer blocks over a small timeframe, rather than a slightly higher costing /24; thereby, increasing global routing table fragmentation.<br>
</div><div><br></div><div>(8)</div><div>And I would say that at this point, the /24 minimum is not an arbitrary minimum.</div><div>By de-facto standard, no longer prefix is permissible to be announced.</div><div><br></div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Policy statement:<br>
Remove all instances in 8.2, 8.3, and 8.4 which set a minimum transfer size of a /24.<br></blockquote></div>-- <br>-JH</div></div>