Absolutely… That is current policy in the ARIN region and it is working well.
The reality is that the amount saved by doing non-nibble boundary allocations is insignificant compared to the likely increase in human factors related errors induced and other varieties of inconvenience (RPKI difficulties, DNSSEC difficulties, etc.) In reality, there are probably well under 1,000,000 organizations that could justify more than a /28 (i.e. a /24) world wide. Probably at most a few million ISPs that would be able to justify more than a /32 (i.e. a /28, serving more than 50,000 customers), I think we’re fine. If it turns out I’m wrong and we burn through 2000::/3 this way in less than 50 years, than I will happily admit it and help anyone who is interested draft more restrictive policies for the remaining untouched ~3/4 of IPv6 address space. So far, we haven’t even managed to polish off a /12 in any region. Owen On Sep 17, 2014, at 4:07 PM, Elvis Velea <el...@velea.eu> wrote: > Hi Owen and Mike, > > can you explain why /28 and not /29? > > Why waste so much and use only nibble boundaries? What would you accept if > someone needs more than a /28, allocation of a /24? > > Kind regards, > Elvis > > On 18/09/14 06:24, HENDERSON MIKE, MR wrote: >> Just for the avoidance of any doubt, I completely agree with Owen's position >> on this matter. >> >> To reiterate: >> · I can accept that sparse allocations already made on /29 >> boundaries can be expanded to fill the entire /29, if there is no room to >> expand them to a /28. >> · I do not agree that any new/ 29 allocations should be made, the >> next size above /32 should be /28 >> >> >> Regards >> >> >> Mike >> >> -----Original Message----- >> From: sig-policy-boun...@lists.apnic.net >> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong >> Sent: Thursday, 18 September 2014 6:16 a.m. >> To: "(Tomohiro -INSTALLER- Fujisaki/藤崎 智宏)" >> Cc: sig-policy@lists.apnic.net >> Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 >> default allocation size >> >> Yes, I still feel it misses my point completely. >> >> I have no problem with expanding the existing reservations which are bounded >> at /29 to /29. >> >> I don’t want to see us move the default allocation in the sparse allocation >> world to larger than /32. Larger than /32 should require additional >> justification for those blocks. >> >> Further, I don’t want to see us creating a default at a non-nibble boundary. >> For organizations that show need for larger than a /32, I would support a >> default of /28, but will continue to oppose a default expansion to /29. >> >> Owen >> >> On Sep 16, 2014, at 6:59 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) >> <fujis...@syce.net> wrote: >> >> > >> > Hi, >> > >> > Thank you so much for your comments. >> > >> > Here, just I would like to confirm, >> > >> > | 1. unrestricted issuance of /29s to every >> > organization regardless of needs. >> > >> > I've added some texts that LIRs would like to to obtain a additional >> > block larger than /32 need to demonstrate their needs in version 3 >> > (prop-111-v003). >> > >> >> From the mail I sent on 1st August: >> > | >> > | I submitted revised version of: >> > | “prop-111: Request-based expansion of IPv6 default allocation size" >> > | >> > | At the last policy sig discussion, I got concern about address >> > | allocation without any constraint, and some criteria should be added >> > | to expand the block size. >> > | >> > | In this revised proposal, I added the requirement to demonstrate >> > | need for both initial and subsequent allocations to reflect such >> > opinions. >> > | >> > | For initial allocation: >> > | > The organizations >> > | > can receive up to /29 by providing utilization information of the >> > whole >> > | > address space. >> > | >> > | For subsequent allocation: >> > | > LIRs that hold one or more IPv6 allocations are able to request >> > | > extension of each of these allocations up to a /29 without meeting >> > | > the utilization rate for subsequent allocation by explaining >> > | > how the whole address space will be used. >> > >> > # The wording is slightly different from latest (v004) version. >> > >> > Do you think corrent text is not enough? >> > >> > Yours Sincerely, >> > -- >> > Tomohiro Fujisaki >> > * sig-policy: APNIC SIG on resource management policy >> > * >> > _______________________________________________ >> > sig-policy mailing list >> > sig-policy@lists.apnic.net >> > http://mailman.apnic.net/mailman/listinfo/sig-policy >> >> * sig-policy: APNIC SIG on resource management policy >> * >> _______________________________________________ >> sig-policy mailing list >> sig-policy@lists.apnic.net >> http://mailman.apnic.net/mailman/listinfo/sig-policy >> The information contained in this Internet Email message is intended for the >> addressee only and may contain privileged information, but not necessarily >> the official views or opinions of the New Zealand Defence Force. If you are >> not the intended recipient you must not use, disclose, copy or >> distribute this message or the information in it. If you have received this >> message in error, please Email or telephone the sender immediately. >> >> >> * sig-policy: APNIC SIG on resource management policy >> * >> _______________________________________________ >> sig-policy mailing list >> sig-policy@lists.apnic.net >> http://mailman.apnic.net/mailman/listinfo/sig-policy > > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/sig-policy
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
