I am familiar with Owen’s arguments, and he and I have agreed to disagree in the past many times. -- Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Thu, Sep 18, 2014 at 9:35 AM, Owen DeLong <o...@delong.com> wrote: > 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 > * 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
