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 <[email protected]> wrote: > >> On Jan 9, 2015, at 1:48 PM, Owen DeLong <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On Jan 9, 2015, at 10:33 , Karl Brumund <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> On Jan 8, 2015, at 5:40 PM, Heather Schiller <[email protected] >>>> <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> >>>> 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: [email protected] <mailto:[email protected]> >>>> >>>> >>>> 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 ([email protected] >>>> <mailto:[email protected]>). >>>> 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 [email protected] <mailto:[email protected]> if you experience any >>>> issues. >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List ([email protected] >>>> <mailto:[email protected]>). >>>> 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 [email protected] <mailto:[email protected]> if you experience any >>>> issues. >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List ([email protected] >>> <mailto:[email protected]>). >>> 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 [email protected] <mailto:[email protected]> if you experience any >>> issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
