Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
My reading of the policy proposal is that it aims to allow people who received allocations under the legacy allocation scheme to expand their address space in a contiguous fashion without having to shift out of their existing address space. Maybe I'm being dense but how are the restricted from doing this under the current policy framework? They can extend up to a /29 today if they have the need. If they need more then they get two block or renumber. Thats the current framework, this policy doesn't really change that as far as I can tell. * 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 Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
On 25 February 2015 at 07:13, Dean Pemberton d...@internetnz.net.nz wrote: +1 to most of what Dean says. My point is that if you need more than a /32, then you should be able to get a /28 rather than having to make a /[29..31] work. It's my understanding that current policy allows just that. If you need a /28 then APNIC will be able to allocate you one. It might not be an extension of your existing allocation if you were one of the early adopters (limited to a /29 boundary), but this policy doesn't provide anything new. All it proposes is that anyone in the position of having an allocation from: 2001:0200::/23 2001:0c00::/23 2001:0e00::/23 2001:4400::/23 Can request their allocation be extended to a /29 without any further justification needed. Owen opposes this as it wouldn't support allocation on a byte boundary (/28). That is never going to be possible for allocations within this block as they were initially allocated too close together. I oppose this on the grounds that it violates needs based allocation guidelines AND non byte boundary allocation for IPv6. So you would support it if it only violated one of those two concerns? A way forward that I would support is: 1. Have the hostmasters confirm that a member with an allocation in this block could, if justified, receive an allocation up to a /29 by extending their current allocation. 2. Have the hostmasters confirm that a member with an allocation in this block could, if justified, swap the allocation for one allocated from a different block where the /29 restriction on growth did not apply. 3. Withdraw this proposal. My reading of the policy proposal is that it aims to allow people who received allocations under the legacy allocation scheme to expand their address space in a contiguous fashion without having to shift out of their existing address space. Given that the address space between the legacy /32s is completely wasted at present, I don't see an issue with removing the justification requirements in this specific case (it's been mentioned that we're setting a dangerous precedent - I'd argue that leaving the space wasted if we have a technically feasible way to make better utilisation of it is a more dangerous precedent). I do not see an issue with this, given the specific limitations which are documented in the proposal. We have to accept that (short of handing everyone with a legacy allocation a new allocation based on today's allocation policy and forcing them to move over to it, handing back their legacy allocation - and I believe that the fact that this proposal is even being considered means we'd not go down that path) we will never resolve the requirement for contiguous address space within the legacy allocation ranges without allowing non-byte allocations. So, in my mind, the issue comes down to Do we want to allow allocation on non byte boundaries [in a limited sense, only within the legacy allocation policy blocks] in order to allow us to better utilise what is currently wasted space, and provide a non-disruptive allocation expansion capability for those who's only crime was to ask for their allocation when the policy was different to what it is now? In the end, I believe that we do want to do this. And thus, in the absence of an alternative policy proposal which resolves the issues this one does, I support this proposal. * 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 Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
On Tue, Feb 24, 2015 at 7:13 AM, Masato Yamanishi myama...@gmail.com wrote: Q1. Is the benefit larger than the concern or not? What benefit? I'm not seeing one here. As far as I can see there is nothing stopping an LIR with one of these historical allocations (a /32 for example) coming back to APNIC, requesting more address space, demonstrating need, and being allocated that additional space. What this proposal seems to be advocating is that each of the LIRs be 'gifted' up to a /29 without having to demonstrate any need what so ever. I oppose this policy on those grounds alone. If the policy were to place a needs based assessment on the LIR, then the proposal would not be required at all and we would be able to proceed under the rules we have today. Q2. Does the alternative solution proposed by Owen resolve this problem also? Owen's solution is available to people today. eg, If I have a /32 and I want to grow this to a /28 but there is only a /29 possible under the allocation models, then I can request a /28 from a different block and renumber into it, returning the /32. I believe people have been doing similar things in the IPv4 world for a while. In it's current form the policy is either not required (members can get additional allocations if required), or a dangerous precident (removal of needs based allocation for IPv6). I do not support this proposal in it's current form. Dean * 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 Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
On Feb 3, 2015, at 7:47 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) fujis...@syce.net wrote: Hi Owen, Mike, Thank you for your comments. I'm the author of prop-112. The purpose of this policy proposal is not to align the boundary but to utilize unused space. Up to /29 is reserved for each /32 in the legacy space. I understood that from the beginning. I oppose that purpose. I would support policy that provided nibble-aligned boundaries. I hope this is sufficiently clear. | From: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong | Sent: Wednesday, 4 February 2015 4:05 p.m. | To: Masato Yamanishi | Cc: sig-policy@lists.apnic.net | Subject: Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space | | I will again oppose this as written. I would much rather see policy deliver nibble-boundary based allocations. | | I would rather see such organizations issued new /28s than expand these /32s into /29s. And renumbering will be necessary for this expansion, and the legacy space folders have used their address space for a long time, it might be difficult. No, I am not proposing that anyone be required to renumber. I am proposing giving them a second prefix, requesting that they not make any new assignments in the old prefix and that when or if it dies of attrition, the old prefix be returned. Technically, I also think nibble boundary is reasonable, but that should be considered in other proposal. Then I oppose this proposal as written. I made a proposal for nibble boundaries, but it was rejected, largely due to misunderstandings and some difficulties with power during the meeting where I was presenting the proposal remotely. Owen * 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 Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
On Feb 3, 2015, at 8:12 PM, Robert Hudson hud...@gmail.com wrote: On 4 February 2015 at 14:54, Dean Pemberton d...@internetnz.net.nz mailto:d...@internetnz.net.nz wrote: There are a number of things that concern me about this proposal. 1) it doesn't appear to support needs based allocation 2) it doesn't support allocation on nibble boundaries which operators have said repeatedly is a major issue. As I read it... The proposal addresses only organisations who already have /32 allocations in the legacy IPv6 block (the IP ranges this includes are defined in the proposal). The allocation policy in the legacy block was effectively to carve out a /29, but then only provide the applicant with a /32 out of this /29 - meaning the gap between the /29 and the /32 remains un-allocated. That is correct. However, rather than expanding this swamp, I would support issuing additional /28s to these organizations and draining the early allocation swamp through attrition. Prop-112 simply proposes that the owner of one of these /32 allocations can, if the require it, request to fill out the /29 which is allocated to them in the back-end, so that they end up with a contiguous block of IP address space. It is not possible to stretch this to a nibble boundary (/28), because the next allocation in the legacy IPv6 block could/would overlap this. Correct, hence my suggestion that they simply be issued new /28s. The proposal does NOT impact /32 allocations that were made since the newer policy of sparse allocation was introduced. Those are left to be dealt with under the existing rules. If the proposal is not accepted, the gap between /32 and /29 is wasted for every allocation within the legacy IPv6 block. This wastes 30,064,771,072 /64 networks, unless a policy is proposed and approved to somehow use this address space in another fashion. Note there are actually multiple blocks as pointed out. Forever is a very long time. The better solution, which does not waste all of them forever, is to allocate new /28s to those organizations that need more than a /32 ask that they not make any new allocations or assignments within the original /32, and return the /32 when or if they ever vacate it through attrition. For organizations that are lucky enough to have the correct neighbor vacate their /32, their prefix could, then, be expanded to a /28 without issue. Even with this policy, most of that space will remain wasted anyway, it will just be wasted in a different place where it can never be used for a different purpose. I'm happy to be corrected on any of this. But if my understanding is correct, the benefits of this proposal vastly outweigh any negatives, and I believe SAGE-AU will be supporting it. They do not, actually. While 30,064,771,072 sounds like a lot of /64s, the simple reality is that when you’re handing them out to end-users 65,536 at a time and to ISPs 4,294,967,296 at a time (minimum), it’s really not so many. When you consider that RIRs are given more than 1024 times that amount of space each time they apply to IANA and that no RIR has even come close to needing a second /12 from IANA so far, I think it is better to hold that particular space in reserve until its current mess is cleaned up through attrition, even if that never happens. Owen * 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 Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
On Feb 3, 2015, at 8:12 PM, Robert Hudson hud...@gmail.com mailto:hud...@gmail.com wrote: On 4 February 2015 at 14:54, Dean Pemberton d...@internetnz.net.nz mailto:d...@internetnz.net.nz wrote: There are a number of things that concern me about this proposal. 1) it doesn't appear to support needs based allocation 2) it doesn't support allocation on nibble boundaries which operators have said repeatedly is a major issue. As I read it... The proposal addresses only organisations who already have /32 allocations in the legacy IPv6 block (the IP ranges this includes are defined in the proposal). The allocation policy in the legacy block was effectively to carve out a /29, but then only provide the applicant with a /32 out of this /29 - meaning the gap between the /29 and the /32 remains un-allocated. That is correct. However, rather than expanding this swamp, I would support issuing additional /28s to these organizations and draining the early allocation swamp through attrition. Prop-112 simply proposes that the owner of one of these /32 allocations can, if the require it, request to fill out the /29 which is allocated to them in the back-end, so that they end up with a contiguous block of IP address space. It is not possible to stretch this to a nibble boundary (/28), because the next allocation in the legacy IPv6 block could/would overlap this. Correct, hence my suggestion that they simply be issued new /28s. The proposal does NOT impact /32 allocations that were made since the newer policy of sparse allocation was introduced. Those are left to be dealt with under the existing rules. If the proposal is not accepted, the gap between /32 and /29 is wasted for every allocation within the legacy IPv6 block. This wastes 30,064,771,072 /64 networks, unless a policy is proposed and approved to somehow use this address space in another fashion. Note there are actually multiple blocks as pointed out. Forever is a very long time. The better solution, which does not waste all of them forever, is to allocate new /28s to those organizations that need more than a /32 ask that they not make any new allocations or assignments within the original /32, and return the /32 when or if they ever vacate it through attrition. For organizations that are lucky enough to have the correct neighbor vacate their /32, their prefix could, then, be expanded to a /28 without issue. Even with this policy, most of that space will remain wasted anyway, it will just be wasted in a different place where it can never be used for a different purpose. I'm happy to be corrected on any of this. But if my understanding is correct, the benefits of this proposal vastly outweigh any negatives, and I believe SAGE-AU will be supporting it. They do not, actually. While 30,064,771,072 sounds like a lot of /64s, the simple reality is that when you’re handing them out to end-users 65,536 at a time and to ISPs 4,294,967,296 at a time (minimum), it’s really not so many. When you consider that RIRs are given more than 1024 times that amount of space each time they apply to IANA and that no RIR has even come close to needing a second /12 from IANA so far, I think it is better to hold that particular space in reserve until its current mess is cleaned up through attrition, even if that never happens. Owen * 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 Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
I agree with Owen Regards Mike From: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong Sent: Wednesday, 4 February 2015 4:05 p.m. To: Masato Yamanishi Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space I will again oppose this as written. I would much rather see policy deliver nibble-boundary based allocations. I would rather see such organizations issued new /28s than expand these /32s into /29s. Owen On Feb 3, 2015, at 9:55 AM, Masato Yamanishi myama...@gmail.commailto:myama...@gmail.com wrote: Dear SIG members The proposal prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka, Japan on Thursday, 5 March 2015. We invite you to review and comment on the proposal on the mailing list before the meeting. The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this proposal is available at: http://www.apnic.net/policy/proposals/prop-112 Regards Masato -- prop-112-v001: On demand expansion of IPv6 address allocation size in legacy IPv6 space -- Proposer: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]. In late 2006, sparse address allocation mechanism has implemented to manage APNIC IPv6 address pool. The block `2400:::/12' has managed with this mechanism. Before 2006, /29 was reserved for all /32 allocations by sequential allocation method made from those old /23 blocks (Legacy IPv6 block). These reserved blocks might be kept unused in the future. 2. Objective of policy change - This proposal modifies the eligibility for organizations in the legacy IPv6 block to extend their IPv6 address space up to a /29 (/32 -/29) by request basis. 3. Situation in other regions - RIPE-NCC: The policy Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis is adopted in RIPE-NCC and LIRs in RIPE region can get up to /29 by default. 4. Proposed policy solution --- - define 'legacy IPv6 address blocks' 2001:0200::/23 2001:0c00::/23 2001:0e00::/23 2001:4400::/23 - Add following text in the policy document: for Existing IPv6 address space holders LIRs that hold one or more IPv6 allocations in the legacy IPv6 address blocks are able to request extension of each of these allocations up to a /29 without meeting the utilization rate for subsequent allocation and providing further documentation. 5. Advantages / Disadvantages - Advantages: It is possible to utilize address blocks which is potentially unused into the future. Disadvantages: Some people may argue this will lead to inefficient utilization of IPv6 space since LIRs can obtain huge address size unnecessarily. However, this will not happen because larger address size needs higher cost to maintain that address block. 6. Impact on resource holders - NIRs must implement this policy if it is implemented by APNIC. 7. References - [1] IPv6 address allocation and assignment policy http://www.apnic.net/policy/ipv6-address-policy * 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,
Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
Hi Dean, You’ve resumed my thinking ! As long as it doesn't support allocation on nibble boundaries I will oppose it. Regards, Le 4 févr. 2015 à 14:54, Dean Pemberton d...@internetnz.net.nz a écrit : There are a number of things that concern me about this proposal. 1) it doesn't appear to support needs based allocation 2) it doesn't support allocation on nibble boundaries which operators have said repeatedly is a major issue. As such I do not support this proposal in its current form. On Wednesday, 4 February 2015, HENDERSON MIKE, MR michael.hender...@nzdf.mil.nz mailto:michael.hender...@nzdf.mil.nz wrote: I agree with Owen Regards Mike From: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net ] On Behalf Of Owen DeLong Sent: Wednesday, 4 February 2015 4:05 p.m. To: Masato Yamanishi Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space I will again oppose this as written. I would much rather see policy deliver nibble-boundary based allocations. I would rather see such organizations issued new /28s than expand these /32s into /29s. Owen On Feb 3, 2015, at 9:55 AM, Masato Yamanishi myama...@gmail.com wrote: Dear SIG members The proposal prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka, Japan on Thursday, 5 March 2015. We invite you to review and comment on the proposal on the mailing list before the meeting. The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this proposal is available at: http://www.apnic.net/policy/proposals/prop-112 http://www.apnic.net/policy/proposals/prop-112 Regards Masato -- prop-112-v001: On demand expansion of IPv6 address allocation size in legacy IPv6 space -- Proposer:Tomohiro Fujisaki 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]. In late 2006, sparse address allocation mechanism has implemented to manage APNIC IPv6 address pool. The block `2400:::/12' has managed with this mechanism. Before 2006, /29 was reserved for all /32 allocations by sequential allocation method made from those old /23 blocks (Legacy IPv6 block). These reserved blocks might be kept unused in the future. 2. Objective of policy change - This proposal modifies the eligibility for organizations in the legacy IPv6 block to extend their IPv6 address space up to a /29 (/32 -/29) by request basis. 3. Situation in other regions - RIPE-NCC: The policy Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis is adopted in RIPE-NCC and LIRs in RIPE region can get up to /29 by default. 4. Proposed policy solution --- - define 'legacy IPv6 address blocks' 2001:0200::/23 2001:0c00::/23 2001:0e00::/23 2001:4400::/23 - Add following text in the policy document: for Existing IPv6 address space holders LIRs that hold one or more IPv6 allocations in the legacy IPv6 address blocks are able to request extension of each of these allocations up to a /29 without meeting the utilization rate for subsequent allocation and providing further documentation. 5. Advantages / Disadvantages - Advantages: It is possible to utilize address blocks which is potentially unused into the future. Disadvantages: Some people may argue this will lead to inefficient utilization of IPv6 space since LIRs can obtain huge address size unnecessarily. However, this will not happen because larger address size needs higher cost to maintain that address block. 6. Impact on resource holders - NIRs must implement
Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
There are a number of things that concern me about this proposal. 1) it doesn't appear to support needs based allocation 2) it doesn't support allocation on nibble boundaries which operators have said repeatedly is a major issue. As such I do not support this proposal in its current form. On Wednesday, 4 February 2015, HENDERSON MIKE, MR michael.hender...@nzdf.mil.nz wrote: I agree with Owen Regards *Mike* *From:* sig-policy-boun...@lists.apnic.net javascript:_e(%7B%7D,'cvml','sig-policy-boun...@lists.apnic.net'); [mailto:sig-policy-boun...@lists.apnic.net javascript:_e(%7B%7D,'cvml','sig-policy-boun...@lists.apnic.net');] *On Behalf Of *Owen DeLong *Sent:* Wednesday, 4 February 2015 4:05 p.m. *To:* Masato Yamanishi *Cc:* sig-policy@lists.apnic.net javascript:_e(%7B%7D,'cvml','sig-policy@lists.apnic.net'); *Subject:* Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space I will again oppose this as written. I would much rather see policy deliver nibble-boundary based allocations. I would rather see such organizations issued new /28s than expand these /32s into /29s. Owen On Feb 3, 2015, at 9:55 AM, Masato Yamanishi myama...@gmail.com javascript:_e(%7B%7D,'cvml','myama...@gmail.com'); wrote: Dear SIG members The proposal prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka, Japan on Thursday, 5 March 2015. We invite you to review and comment on the proposal on the mailing list before the meeting. The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this proposal is available at: http://www.apnic.net/policy/proposals/prop-112 Regards Masato -- prop-112-v001: On demand expansion of IPv6 address allocation size in legacy IPv6 space -- Proposer:Tomohiro Fujisaki fujis...@syce.net javascript:_e(%7B%7D,'cvml','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]. In late 2006, sparse address allocation mechanism has implemented to manage APNIC IPv6 address pool. The block `2400:::/12' has managed with this mechanism. Before 2006, /29 was reserved for all /32 allocations by sequential allocation method made from those old /23 blocks (Legacy IPv6 block). These reserved blocks might be kept unused in the future. 2. Objective of policy change - This proposal modifies the eligibility for organizations in the legacy IPv6 block to extend their IPv6 address space up to a /29 (/32 -/29) by request basis. 3. Situation in other regions - RIPE-NCC: The policy Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis is adopted in RIPE-NCC and LIRs in RIPE region can get up to /29 by default. 4. Proposed policy solution --- - define 'legacy IPv6 address blocks' 2001:0200::/23 2001:0c00::/23 2001:0e00::/23 2001:4400::/23 - Add following text in the policy document: for Existing IPv6 address space holders LIRs that hold one or more IPv6 allocations in the legacy IPv6 address blocks are able to request extension of each of these allocations up to a /29 without meeting the utilization rate for subsequent allocation and providing further documentation. 5. Advantages / Disadvantages - Advantages: It is possible to utilize address blocks which is potentially unused into the future. Disadvantages: Some people may argue this will lead to inefficient utilization of IPv6 space since LIRs can obtain huge address size unnecessarily. However, this will not happen because larger address size needs higher cost to maintain that address block. 6. Impact on resource holders - NIRs must implement this policy if it is implemented by APNIC. 7. References - [1]
Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
Hi Owen, Mike, Thank you for your comments. I'm the author of prop-112. The purpose of this policy proposal is not to align the boundary but to utilize unused space. Up to /29 is reserved for each /32 in the legacy space. | From: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong | Sent: Wednesday, 4 February 2015 4:05 p.m. | To: Masato Yamanishi | Cc: sig-policy@lists.apnic.net | Subject: Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space | | I will again oppose this as written. I would much rather see policy deliver nibble-boundary based allocations. | | I would rather see such organizations issued new /28s than expand these /32s into /29s. And renumbering will be necessary for this expansion, and the legacy space folders have used their address space for a long time, it might be difficult. Technically, I also think nibble boundary is reasonable, but that should be considered in other proposal. 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
Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
On 4 February 2015 at 14:54, Dean Pemberton d...@internetnz.net.nz wrote: There are a number of things that concern me about this proposal. 1) it doesn't appear to support needs based allocation 2) it doesn't support allocation on nibble boundaries which operators have said repeatedly is a major issue. As I read it... The proposal addresses only organisations who already have /32 allocations in the legacy IPv6 block (the IP ranges this includes are defined in the proposal). The allocation policy in the legacy block was effectively to carve out a /29, but then only provide the applicant with a /32 out of this /29 - meaning the gap between the /29 and the /32 remains un-allocated. Prop-112 simply proposes that the owner of one of these /32 allocations can, if the require it, request to fill out the /29 which is allocated to them in the back-end, so that they end up with a contiguous block of IP address space. It is not possible to stretch this to a nibble boundary (/28), because the next allocation in the legacy IPv6 block could/would overlap this. The proposal does NOT impact /32 allocations that were made since the newer policy of sparse allocation was introduced. Those are left to be dealt with under the existing rules. If the proposal is not accepted, the gap between /32 and /29 is wasted for every allocation within the legacy IPv6 block. This wastes 30,064,771,072 /64 networks, unless a policy is proposed and approved to somehow use this address space in another fashion. I'm happy to be corrected on any of this. But if my understanding is correct, the benefits of this proposal vastly outweigh any negatives, and I believe SAGE-AU will be supporting it. * 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
