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