Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
On Tue, Sep 16, 2014 at 6:40 AM, Jay Daley j...@nzrs.net.nz wrote: Does anyone honestly believe that in the next say 50 years we will have less than 1,048,576 organisations who might have ambitions one day to have a /20 or less than 8,192 who think they are as big and important as the US DoD? (Ignoring the fact that the number of /20s will be less than that given the larger allocations made). I have ambitions of having a /20 IPv6 allocation. Ambitions are easy. But APNIC will ask for justification, I suppose. If the US DoD, or Toyota, can justify a /20, sure, why not? Frankly, given the current state of the Routing Registeries, and RPKI, etc, having BGP announcements on hex-digit boundaries would greatly help troubleshooting by eyeball. I support using /28 , and then /24 , etc, rather than /29 or /27 or whatever. I know this is inefficient, and realise that 50 years from now, it will be seen as stupid and wasteful. But 50 years from now, they are unlikely to care how APNIC handled allocations. -- Sanjeev Gupta +65 98551208 http://sg.linkedin.com/in/ghane * 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
Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
Owen, The Open Source material says variously that US DoD has either a /13 or a /16 · http://en.wikipedia.org/wiki/IPv6_deployment As with IPv4, the Department of Defense holds a larger IPv6 allocation than any other entity, a /13 block, enough to create almost 2.3 quadrillion (2.3×1015) local area networks, 64 times as many as the next largest entity. This appears to rely on: http://royal.pingdom..com/2009/03/26/the-us-department-of-defense-has-42-million-billion-billion-billion-ipv6-addresses/http://royal.pingdom.com/2009/03/26/the-us-department-of-defense-has-42-million-billion-billion-billion-ipv6-addresses/, which says The US DoD has a /13 IPv6 block ... · http://gcn.com/Articles/2007/02/03/DOD-to-allocate-its-IPv6-addresses.aspx?Page=1 The Defense Department has acquired a block of 247 billion IP Version 6 addresses, about equal to 25 percent of the entire IPv4 address space ... this collection of addresses, which in IP talk is known as a /16 (pronounced 'slash 16') Both are fairly old, but someone with better Google skills than I may be able to find a more recent - and possibly more reliable - posting. Regards Mike From: Owen DeLong [mailto:o...@delong.com] Sent: Wednesday, 17 September 2014 9:47 a.m. To: HENDERSON MIKE, MR Cc: sig-pol...@apnic.net; fujis...@syce.net Subject: Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED) The US DOD does not have a /13. I do not know why this myth continues to propagate. Owen On Sep 15, 2014, at 2:11 PM, HENDERSON MIKE, MR michael.hender...@nzdf.mil.nzmailto:michael.hender...@nzdf.mil.nz wrote: I do not agree with the contention that allocations larger than /28 - e.g. /24 , /20 - will be too huge. In my view there are three factors in play here: 1) we are still thinking small, a mind-set caused by the scarcity of IPv4 address space 2) we are not considering use cases in the so-called Internet of Things where there may be requirements for support of huge client address spaces. As a mind experiment, imagine that one day in the not too distant future Toyota will want a /60 or even a /56 for every vehicle they manufacture. At their current rat of production, close to 10 Million vehicles a year, they will need huge allocation rather quickly, and of course so will all the other vehicle manufacturers 3) we are forgetting the historical precedent: the Australian Defence Force was allocated a /20 by APNIC in 2007, and the US Department of Defense already has a /13. So we have at least one organisation in APNIC who already thinks that a /20 is 'just right' rather than 'too huge'. Regards Mike -Original Message- From: sig-policy-boun...@lists.apnic.netmailto:sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Tomohiro -INSTALLER- Fujisaki/?? ?? Sent: Monday, 15 September 2014 11:56 a.m. To: sig-pol...@apnic.netmailto:sig-pol...@apnic.net Subject: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size Hi all, Thank you again for your comments to prop-111. I got several comments for nibble boundary allocation. I think /28 might be OK, but additional allocation after /28 will be too huge with this allocation scheme (that will be /24, /20, ...). Here is current summary of nibble boundary allocation. I would appreciate your additional opinions. Advantages: - ease of address masking and calculation - ease of DNS reverse delegation set up Disadvantages: - LIRs in legacy space cannot extend prefix to /28 - allocation size will be too huge (allocations after /28 will be /24, /20..) Yours Sincerely, -- Tomohiro Fujisaki * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.netmailto: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.netmailto: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
Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
On 16/09/2014, at 9:11 am, HENDERSON MIKE, MR michael.hender...@nzdf.mil.nz wrote: I do not agree with the contention that allocations larger than /28 - e.g. /24 , /20 - will be too huge. In my view there are three factors in play here: 1) we are still thinking small, a mind-set caused by the scarcity of IPv4 address space To the left of the mask or to the right? 2) we are not considering use cases in the so-called Internet of Things where there may be requirements for support of huge client address spaces. As a mind experiment, imagine that one day in the not too distant future Toyota will want a /60 or even a /56 for every vehicle they manufacture. At their current rat of production, close to 10 Million vehicles a year, they will need huge allocation rather quickly, and of course so will all the other vehicle manufacturers This sounds like double counting to me. We are already talking about giving home users a /56 and ISPs a /19 or more and I thought the point of that was that the light bulbs in my house are going to be addressed from my home /56 and my car will get its addresses from the ISP /19. So I don't see why the IoT means one big contiguous address block for all the things from one manufacturer? 3) we are forgetting the historical precedent: the Australian Defence Force was allocated a /20 by APNIC in 2007, and the US Department of Defense already has a /13. So we have at least one organisation in APNIC who already thinks that a /20 is 'just right' rather than 'too huge'. 2^20 is 1,048,576 to the left and 17,592,186,044,416 to the right 2^13 is 8192 to the left and 9,007,199,254,740,992 to the right. (using only 64 bits) Does anyone honestly believe that in the next say 50 years we will have less than 1,048,576 organisations who might have ambitions one day to have a /20 or less than 8,192 who think they are as big and important as the US DoD? (Ignoring the fact that the number of /20s will be less than that given the larger allocations made). cheers Jay Regards Mike -Original Message- From: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Tomohiro -INSTALLER- Fujisaki/?? ?? Sent: Monday, 15 September 2014 11:56 a.m. To: sig-pol...@apnic.net Subject: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size Hi all, Thank you again for your comments to prop-111. I got several comments for nibble boundary allocation. I think /28 might be OK, but additional allocation after /28 will be too huge with this allocation scheme (that will be /24, /20, ...). Here is current summary of nibble boundary allocation. I would appreciate your additional opinions. Advantages: - ease of address masking and calculation - ease of DNS reverse delegation set up Disadvantages: - LIRs in legacy space cannot extend prefix to /28 - allocation size will be too huge (allocations after /28 will be /24, /20..) 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 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 -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley * 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
Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size [SECURITY=UNCLASSIFIED]
On Sep 3, 2014, at 2:12 PM, Masato Yamanishi myama...@japan-telecom.com wrote: Hi Mike, Thank you for you comment and let me clarify your one point. On 2014/09/02 16:07, HENDERSON MICHAEL, MR michael.hender...@nzdf.mil.nz wrote: I do not favour IPv6 allocations on “non-nibble” boundaries, I believe that allocations ought to be made on “nibble” (i.e. 4-bit) boundaries. On that basis, the next allocation larger than /32 would be /28, not /29. Address masking and calculation on /29 boundaries will in my view be quite nasty, and the size of the IPv6 address space is sufficiently large that we need not, and therefore should not, impose such inconveniences on ourselves. Hence, in my IPv6 allocation world, a resource holder who has a demonstrated need (for whatever value of ‘need’ seems appropriate) for address space larger than /32, should be allocated a /28. If they are ‘growing’ an existing /32, then the new /28 would very preferably be one that includes the currently-allocated /28. However, I understand the current situation is that the ‘legacy’ IPv6 address allocation was for smaller allocations within blocks on /29 boundaries, if I read the Proposition correctly. As a special case only, I would support the allocation of these ‘legacy /29’ blocks. The provisos being that firstly they do fall into this ‘legacy’ category, and that secondly it is not possible (owing to allocation to a third party) to allocate a /28 to the relevant resource holder But this proposal is NOT ONLY for the special case. Every organizations, which are new comers, “legacy” IPv6 space holder, and existing IPv6 space holder with sparse allocation mechanism, will be eligible for /29 by providing necessary information as shown in Sec.4. Which I believe is a flaw in the proposal. So, can you share your preference for current proposed text as it is? I do not support the proposal as written. I would support it if /28s were issued whenever possible and /29s were only issued in cases where the existing assignment or allocation cannot be expanded to at least /28. Owen 4. Proposed policy solution - Change the text to 5.2.2 Minimum initial allocation size of current policy document as below: Organizations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. The organizations can receive up to /29 by providing utilization information of the whole address space. - Add following text in the policy document: for Existing IPv6 address space holders 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. Rgs, Masato * 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
Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size [SECURITY=UNCLASSIFIED]
I do not favour IPv6 allocations on “non-nibble” boundaries, I believe that allocations ought to be made on “nibble” (i.e. 4-bit) boundaries. On that basis, the next allocation larger than /32 would be /28, not /29. Address masking and calculation on /29 boundaries will in my view be quite nasty, and the size of the IPv6 address space is sufficiently large that we need not, and therefore should not, impose such inconveniences on ourselves. Hence, in my IPv6 allocation world, a resource holder who has a demonstrated need (for whatever value of ‘need’ seems appropriate) for address space larger than /32, should be allocated a /28. If they are ‘growing’ an existing /32, then the new /28 would very preferably be one that includes the currently-allocated /28. However, I understand the current situation is that the ‘legacy’ IPv6 address allocation was for smaller allocations within blocks on /29 boundaries, if I read the Proposition correctly. As a special case only, I would support the allocation of these ‘legacy /29’ blocks. The provisos being that firstly they do fall into this ‘legacy’ category, and that secondly it is not possible (owing to allocation to a third party) to allocate a /28 to the relevant resource holder Regards Mike From: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Masato Yamanishi Sent: Wednesday, 3 September 2014 10:40 a.m. To: sig-pol...@apnic.net Subject: Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size Dear Colleagues, While next APNIC meeting is reaching 3 weeks later, we saw just couple of comments for this revised proposal. Our process for reaching consensus relies on hearing the opinions of those who can only take part via this list as well as those who can attend the Policy SIG sessions at the APNIC meetings. It would be very helpful for the community to hear any opinions including favor or against. Regards, Policy SIG Chairs, On 2014/07/31 11:42, Masato Yamanishi myama...@japan-telecom.commailto:myama...@japan-telecom.com wrote: Dear SIG members A new version of the proposal “prop-111: Request-based expansion of IPv6 default allocation size has been sent to the Policy SIG for review. Information about earlier versions is available from: http://www.apnic.net/policy/proposals/prop-111 You are encouraged to express your views on the proposal: - Do you support or oppose the proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Please find the text of the proposal below. Kind Regards, Andy and Masato -- prop-111-v003 Request-based expansion of IPv6 default allocation size -- Author: Tomohiro Fujisaki fujis...@syce.netmailto:fujis...@syce.net 1. Problem statement IPv6 minimum allocation size to LIRs is defined as /32 in the IPv6 address allocation and assignment policy[1]. It's better to expand this minimum allocation size up to /29 (/32 - /29) since: - Before sparse allocation mechanism implemented in late 2006, /29 was reserved for all /32 allocations by sequential allocation method made from those old /23 blocks. These reserved blocks might be kept unused in the future. - Sparse allocation mechanism was implemented in late 2006 with a /12 allocation from the IANA. Under the sparse allocation mechanism, there is no reservation size defined, and the space between allocations continues to change, depending on the remaining free pool available in APNIC. However, the APNIC guidelines for IPv6 allocation and assignment requests[2] stated: In accordance with APNIC's IPv6 address allocation and assignment policy, where possible, subsequent delegations to the same resource holder are made from an adjacent address block by growing the delegation into the free space remaining, unless disaggregated ranges are requested for multiple discrete networks. So, it is expected that allocation up to /29 is guaranteed for consistency with allocations above. Based on the current situation, contiguous allocation of /29 can still be accommodated even under the sparse allocation mechanism (Current /32 allocations from the /12 block can grow up to /24 at this stage). - After amended HD Ratio (0.94) and base calculation size (/56) was introduced (prop-031 and prop-033), to obtain address blocks larger than /32 and to request additional address blocks became harder especially for small and middle size ISPs. - For traffic control purpose, some LIRs announce address blocks longer than /32 (e.g. /35). However, some ISPs may set filters to block address size longer than /32 since some filtering guidelines recommend to filter longer prefix than /32([3][4]). If LIRs have
Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size [SECURITY=UNCLASSIFIED]
On Wed, Sep 3, 2014 at 7:07 AM, HENDERSON MICHAEL, MR michael.hender...@nzdf.mil.nz wrote: However, I understand the current situation is that the ‘legacy’ IPv6 address allocation was for smaller allocations within blocks on /29 boundaries, if I read the Proposition correctly. As a special case only, I would support the allocation of these ‘legacy /29’ blocks. The provisos being that firstly they do fall into this ‘legacy’ category, and that secondly it is not possible (owing to allocation to a third party) to allocate a /28 to the relevant resource holder I agree. As a small operator, who spends time helping other small operators offer IPv6, it would greatly benefit us if allocation (and hence our BGP announcements and filters) were on a /32 or /28. To those who are already within a /29, and the adjacent /29 is also allocated, a /29 is the least evil. But new allocations should be of, or from, a /28. -- Sanjeev Gupta +65 98551208 http://sg.linkedin.com/in/ghane * 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
