That's one of my concerns Elvis... If we accept the argument that we'll only allocate on hex-char boundaries, then it means that we're wasting more and more addresses as time goes by. We'll be having this discussion in a little while about /24s rather than /27s then it will be /20s rather than......
I once had someone swear that they would never use the 'letters' in the IPv6 address because it made the addresses look 'strange'. They ended up wasting over a third of their address space. What is being suggested here is almost as crazy. Regards, Dean -- 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:07 AM, 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
