On Sep 17, 2014, at 4:59 PM, Elvis Velea <el...@velea.eu> wrote: > Hi Owen, > > what has ARIN to do with the policy in APNIC?
Nothing at all… Simply pointing out that there is experience with such a policy and that the experience has been positive. > I could also justify my arguments by saying that the RIPE policy allows up to > a /29 per member.. and that policy works very well as well. Fair enough. So if policy up to a /29 works well and policy allowing /28s works well, why not favor /28s over /29s? What is the advantage of /29s? > Let's not use other regions' policies to justify disapproval of this policy > proposal. Especially when both ARIN and RIPE have different policies that > work very well. I’m not favoring disapproval of this policy. I’m favoring modifying it to allow /28s. > I would like to ask you to explain what kind of errors/difficulties may > induce the allocation of a /29 (instead of a /28) in regards to RPKI and > DNSSSEC. I do not really understand that part (sorry, I am not very > technical). If it's fat-fingering you are talking about, that can happen > regardless of the size of the allocation. When computing net masks and which networks are within/outside of a given prefix, things which fall on nibble boundaries are readily visible to human eyes. If I have a prefix, for example, of 2620:0:930::/48, I know that anything which starts with 2620:0:930:… is within that prefix. If I make it a /29, then instead of 2620:0:930:… it becomes 2620:0:930:0… through 2620:0:930:7… It’s even worse for 28s vs. 29s… For example, 2601:5ca0::/28 includes everything that starts with 2601:5ca?:… However, 2601:5ca8::/29 is everything from 260:15ca8:… thru 2601:5caf:… Delegating a /29 requires 8 NS records per name server serving the ip6.arpa zones in question. Delegating a /28 requires 1. I believe that RPKI has similar issues to DNS. > I find it surprising that you oppose to a policy proposal that would allow > members of APNIC to use more IPv6 addresses just because the policy does not > say 'more than more' (/28s instead of /29s). Perhaps it is because you are not technical and have not had an operational role and experience. Owen > > cheers, > elvis > > On 18/09/14 09:35, Owen DeLong 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
