<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 10, 2014 at 3:50 PM, David Huberman <span dir="ltr"><<a href="mailto:David.Huberman@microsoft.com" target="_blank">David.Huberman@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am the author and I support this policy. Jimmy, I'd like to respond to your points:<br></blockquote><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Obviously, I disagree :) I think it is a forward looking policy, asking the PPML to remove an arbitrary minimum barrier which is the purview of network operators, not </blockquote>
<div> </div><div>Hi. The choice of announced prefix size is not entirely within the purview of network operators. IN FACT; whatever address size of an allocation ARIN chooses to allow to be created, may tend to be highly "coercive", network operators may have little ability to refuse the prefix, once ARIN deems it legitimate.</div>
<div><br></div><div>The minimum size of a block allocated or transferred is well within the purview of ARIN address policy, and a major factor causing the minimum to be /24 instead of /32 IS hierarchical addressing, aggregation, AND also routable prefix size.</div>
<div><br></div><div>Routing considerations DO have a legitimate affect on RIR addressing policy. Which is not entirely within the purview of network operators.</div><div><br></div><div>However, the ARIN RIR community itself INCLUDES network operators.<br>
</div>
<div>The establishment of a minimum allocation and transfer unit, is well within ARIN's stewardship responsibilities.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
what size prefixes I will, and will not, export to my peers. The IETF and the engineering community have never given that authority to ARIN<br></blockquote><div><br></div><div>ARIN policy has the authoritiy to determine what address block sizes that ARIN issues.</div>
<div>Restricting allocations smaller than a /24 services legitimate stewardship requirements.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I characterize it as "forward looking" because it is removing an arbitrary barrier to success for later in the 8.3 and 8.4 transfer market lifetimes.<br>
</blockquote><div><br></div><div>Requirement that blocks contain a reasonable minimum number of addresses, so that routes can be aggregated, is not an arbitrary barrier --- it is a reasonable barrier, that any responsible internet registry, fulfilling its address stewardship requirements, would have a minimum size for allocations, transfers, etc.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>You're wrong here, sorry. This policy only affects text in 8.2, 8.3, and 8.4, which are transfer sections. Transfers are going to be the only significant work that the Registry does in the foreseeable future, so it's very relevant to tomorrow's ARIN.<br>
</div></blockquote><div><br></div><div>IPv6 related transfers and allocations yes. IPv4 is not particularly relevant to tomorrow's ARIN.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the world today, 8.3 transfers are very active. Hundreds of blocks are changing hands every year. That's almost as many allocations and assignments as ARIN gives </blockquote><div><br></div><div>Yes.... mere _hundreds_ every year, compared to _tens of thousands_ of new delegations. The fact is; the true lack of interest in transfers, Versus IPv6 allocation, will have unknowns until 20000+ delegations CAN'T happen every year, anymore.</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"><div>> (4) IPv6 is likely to be adopted more heavily, obviating the usefulness of any attempts to increase the number of resource transfers occuring.<br>
<br>
</div>Strongly disagree. Despite the best efforts of fine engineers like Owen DeLong and his excellent employer Hurricane Electric, IPv6 is already a legacy protocol, and </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
adoption is very very slow. Moreover, the number of IPv4-only networks dwarfs the </blockquote><div><br></div><div>All signs point to the claim of V6 adoption being slow, as completely, utterly incorrect.</div><div><br>
</div><div>"IPv6 is a legacy protocol" is certainly a new one.</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"><div>
> (6) 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<br>
<br>
</div>This isn't 1995 or even 2005 anymore. We have over 400,000 routes in the DFZ and large network routing tables are in the millions. 10,000 or even 100,000 sub-/24 route announcements isn't going to stop BGP from converging.<br>
</blockquote><div><br></div><div>"100,000" extra sub /24 announcements, is a dramatic underestimate of what is likely to happen, if there are a large number of sub-/24 transfers.</div><div><br></div><div>
Not that 10 to 100K extra routes is anything to sneeze at either.</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">
<div>> (7) A problem is: as long as routes for these prefixes would hypothetically be accepted, the networks who "see fit to move smaller blocks around and fragment /24s into<br>
> 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.<br>
<br>
</div>That's not the purview of ARIN. It is up to each individual network operator to decide what routes she will, or will not, accept.<br></blockquote><div><br></div><div>No, the effect of any policy changes on routing considerations' and potential network stability are definitely within the full purview of ARIN.</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">
<div>> (8) And I would say that at this point, the /24 minimum is not an arbitrary minimum. By de-facto standard, no longer prefix is permissible to be announced.<br>
<br>
</div>Strongly disagree. As Bill Manning always said, an operator will route whatever I pay them to route.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>-JH</div></div>