[arin-ppml] Requesting Feedback: Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10

Sat Jan 10 03:15:40 EST 2015

BCP38 was out before RIRs started moving down to /24s. It didn’t take long for ISPs to adapt to /24s from /20s. I don’t think BCP38 experience is particularly telling on this one. BCP38 has some complexities in certain environments. Setting up a simple prefix-length filter or modifying one for a particular prefix, OTOH, is pretty well trodden path for most ISPs.

Owen

> On Jan 9, 2015, at 10:59 , Karl Brumund <kbrumund at dyn.com> wrote:
> 
>> On Jan 9, 2015, at 1:48 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
>> 
>>> 
>>> On Jan 9, 2015, at 10:33 , Karl Brumund <kbrumund at dyn.com <mailto:kbrumund at dyn.com>> wrote:
>>> 
>>>> On Jan 8, 2015, at 5:40 PM, Heather Schiller <heather.skanks at gmail.com <mailto:heather.skanks at gmail.com>> wrote:
>>>> 
>>>> Happy New Year PPML!
>>>> 
>>>>  As one of the shepherds of this policy, it would be very helpful to hear from the community on this proposal.  Comments for or against are welcome, as are any questions.
>>>> 
>>> 
>>> Reading 2008-5, it appears that the authors at the time expected that ISPs may relax their filter rules to allow longer than /24 routes. Given that doing so would encourage a lot more deaggregation of existing /24s, I find it unlikely that ISPs will permit longer than /24 in any appreciable number to matter.
>>> Thus it seems that having a minimum of /28 for direct allocations is impractical, and that these would happen through assignments, as today.
>> 
>> As one of the authors of 2008-5, yes, you are (mostly) correct.
>> 
>> I didn’t expect ISPs to relax their filters in general, but I did expect ISPs might relax their filters for this particular designated block. I don’t see any reason that wouldn’t be possible even now as that would not encourage (or even allow) deaggregation of existing /24s.
>> 
>> We are talking about a relatively small block being preserved to provide minimal resources for (primarily) post-runout new entrants (or at least that was my intent at the time of writing).
>> 
>>> I see nothing wrong with 2014-22, but am open to hearing other comments.
>> 
>> I see no advantage to 2014-22. I think when this block comes into play, since it is a particular designated block, ISPs will react relatively quickly to allow longer prefixes within this space when it becomes necessary.
> 
> Given the pain of even getting some of BCP38 implemented, I am having trouble sharing Owen’s optimism that this would happen. I would like to, I really sincerely honestly would, but then again I would also like to route in a world that implemented BCP38.
> 
> …karl
> 
>> 
>> Since it is only a single /10, even at /28, we’re talking about a maximum of 16,384 additional prefixes.
>> 
>> Owen
>> 
>>> 
>>> …karl
>>> 
>>>> You may want to read this report from RIPE Labs, specifically discussing the existing policy, and tests they did on routability of small prefixes. 
>>>> 
>>>> https://labs.ripe.net/Members/emileaben/propagation-of-longer-than-24-ipv4-prefixes <https://labs.ripe.net/Members/emileaben/propagation-of-longer-than-24-ipv4-prefixes>
>>>> 
>>>> Thanks!
>>>> --Heather
>>>> 
>>>> 
>>>> ---------- Forwarded message ----------
>>>> From: ARIN <info at arin.net <mailto:info at arin.net>>
>>>> Date: Tue, Nov 25, 2014 at 3:35 PM
>>>> Subject: [arin-ppml] Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10
>>>> To: arin-ppml at arin.net <mailto:arin-ppml at arin.net>
>>>> 
>>>> 
>>>> On 20 November 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-214 Removal of Minimum in Section 4.10" as a Draft Policy.
>>>> 
>>>> Draft Policy ARIN-2014-22 is below and can be found at:
>>>> https://www.arin.net/policy/proposals/2014_22.html <https://www.arin.net/policy/proposals/2014_22.html>
>>>> 
>>>> You are encouraged to discuss the merits and your concerns of Draft
>>>> Policy 2014-22 on the Public Policy Mailing List.
>>>> 
>>>> The AC will evaluate the discussion in order to assess the conformance
>>>> of this draft policy with ARIN's Principles of Internet Number Resource
>>>> Policy as stated in the PDP. Specifically, these principles are:
>>>> 
>>>>   * Enabling Fair and Impartial Number Resource Administration
>>>>   * Technically Sound
>>>>   * Supported by the Community
>>>> 
>>>> The ARIN Policy Development Process (PDP) can be found at:
>>>> https://www.arin.net/policy/pdp.html <https://www.arin.net/policy/pdp.html>
>>>> 
>>>> Draft Policies and Proposals under discussion can be found at:
>>>> https://www.arin.net/policy/proposals/index.html <https://www.arin.net/policy/proposals/index.html>
>>>> 
>>>> Regards,
>>>> 
>>>> Communications and Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>> 
>>>> 
>>>> ## * ##
>>>> 
>>>> 
>>>> Draft Policy ARIN-2014-22
>>>> Removal of Minimum in Section 4.10
>>>> 
>>>> Date: 25 November 2014
>>>> 
>>>> Problem Statement:
>>>> 
>>>> The current section 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment creates an issue where a small new organization that requires an IPv4 allocation or assignment would potentially receive a block that today would be unroutable and therefore unusable for it intended purposes.
>>>> 
>>>> Policy statement:
>>>> 
>>>> Change
>>>> 
>>>> "This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block."
>>>> 
>>>> To
>>>> 
>>>> "This block will be subject to an allocation of /24. ARIN should use sparse allocation when possible within that /10 block."
>>>> 
>>>> Timetable for implementation: Immediate
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
>>>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
>>>> 
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
>>>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
>>> 
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
>>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150110/66d9e202/attachment.htm>