Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
On Sep 17, 2014, at 7:23 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) fujis...@syce.net wrote: Hi Skeeve, Thank you for your comment! From: Skeeve Stevens ske...@v4now.com Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED) Date: Thu, 18 Sep 2014 12:02:43 +1000 | So... balancing the two.. I support increasing the standard large | allocation to a /28. I have two concerns. I'm sorry for repeating these. 1. LIRs in legacy space, who has been tackling IPv6 deployment from the early stage could not expand their address space to /28. I think it's not fair. LIRs in such a position should be given the following choices: 1. Expand to a /29 and stay where they are. 2. Receive a new /28 with no requirement to return their existing /32, but a polite request that they do so if it later becomes vacant and encouragement not to allocate new things within the /32. In this way, I think it can be made perfectly fair. 2. If we employ 'nibble boundary' allocation for technical reasons, the additional subsequent allocation should be /24, /20, and so on. It might be meaningless if only first allocation aligns. To do that, I think we need difference proposal since there will be so big changes in our policy. Yes… I agree that this should be done. I would have no problem with that being addressed in a separate policy proposal. And one more, ARIN implements totally different address allocation scheme, which discussed also in our APNIC region as prop-098. I'm not sure but nibble boundary allocation scheme will be suitable under that policy. Unfortunately, that discussion was seriously hampered by technical difficulties and the author’s inability to be present at the meeting for the discussion. One person characterized the proposal as an attempt to tell network operators how to run their networks which was completely untrue. It was, as is your proposal, an effort to make it easier for operators that wanted to get larger allocations (within reason). Owen Yours Sincerely, -- Tomohiro Fujisaki From: Skeeve Stevens ske...@v4now.com Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED) Date: Thu, 18 Sep 2014 12:02:43 +1000 | Elvis, | | Owens position has been quite simply explained. | | He does NOT oppose the increase in the size of the allocation just just | wants it done more cleanly. | | Deans argument is that this will potentially waste additional space. | | I see, and actually agree with both positions... I like to conserve | address space, but Owens point is very valid... even if 1 million | organisations took a /28, it would still make minimal impact on the address | space over a significant period. | | But, planning for the future is something we should keep in our mind... | but, not at the detriment of todays operations. | | His point of the number of name servers for reverse delegation for a /29 | being 8 and a /28 being 1 is quite a compelling reason to increase the | default 'larger' allocation to /28. | | So... balancing the two.. I support increasing the standard large | allocation to a /28. | | | ...Skeeve | | *Skeeve Stevens - Senior IP Broker* | *v4Now - *an eintellego Networks service | ske...@v4now.com ; www.v4now.com | | Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve | | facebook.com/v4now ; http://twitter.com/networkceoau | linkedin.com/in/skeeve | | twitter.com/theispguy ; blog: www.theispguy.com | | | IP Address Brokering - Introducing sellers and buyers | | On 18 September 2014 09:59, Elvis Velea el...@velea.eu wrote: | | Hi Owen, | | what has ARIN to do with the policy in APNIC? | 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. | | 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 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. | | 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). | | 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
Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
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.netmailto: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.netmailto: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.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.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
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 mailto: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 mailto: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 mailto: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
Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
Hi Owen, what has ARIN to do with the policy in APNIC? 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. 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 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. 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). 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 mailto: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 mailto: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,
Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
Elvis, Owens position has been quite simply explained. He does NOT oppose the increase in the size of the allocation just just wants it done more cleanly. Deans argument is that this will potentially waste additional space. I see, and actually agree with both positions... I like to conserve address space, but Owens point is very valid... even if 1 million organisations took a /28, it would still make minimal impact on the address space over a significant period. But, planning for the future is something we should keep in our mind... but, not at the detriment of todays operations. His point of the number of name servers for reverse delegation for a /29 being 8 and a /28 being 1 is quite a compelling reason to increase the default 'larger' allocation to /28. So... balancing the two.. I support increasing the standard large allocation to a /28. ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service ske...@v4now.com ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers On 18 September 2014 09:59, Elvis Velea el...@velea.eu wrote: Hi Owen, what has ARIN to do with the policy in APNIC? 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. 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 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. 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). 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 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:
Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
Ok, thinking about this some more, I am still conflicted. There are two schools here... simplicity and conservation. I think worrying about conservation is important. But are we trying to converse needlessly? If we think we will be using v6 in 20 years, I think we are kidding ourselves. With the IoE/IoT, the consumption of address space is going to accelerate in a huge way. If we're not thinking about what is after IPv6, then we're doing ourselves a disservice anyway. But that is the future, and extremely difficult to predict in this area. I think simplicity is better in this case... except if it is not really simple. If we have to alter a significant amount of policy to make it simpler, then it isn't really simple. The question is, how critical is this at the moment? I'd like to see thing simpler, but I'd like to know how complex it would be to implement it - correctly. ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service ske...@v4now.com ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers On 18 September 2014 12:02, Skeeve Stevens ske...@v4now.com wrote: Elvis, Owens position has been quite simply explained. He does NOT oppose the increase in the size of the allocation just just wants it done more cleanly. Deans argument is that this will potentially waste additional space. I see, and actually agree with both positions... I like to conserve address space, but Owens point is very valid... even if 1 million organisations took a /28, it would still make minimal impact on the address space over a significant period. But, planning for the future is something we should keep in our mind... but, not at the detriment of todays operations. His point of the number of name servers for reverse delegation for a /29 being 8 and a /28 being 1 is quite a compelling reason to increase the default 'larger' allocation to /28. So... balancing the two.. I support increasing the standard large allocation to a /28. ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service ske...@v4now.com ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers On 18 September 2014 09:59, Elvis Velea el...@velea.eu wrote: Hi Owen, what has ARIN to do with the policy in APNIC? 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. 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 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. 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). 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
Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
+1 Except that I haven't disagreed with Dean on this for as long as Owen has :) Regards Mike From: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong Sent: Wednesday, 17 September 2014 1:02 p.m. To: Masato Yamanishi Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size I remain opposed so long as we limit this to /29 for everyone. I accept the idea of issuing (up to) the reserved /29s from the non-sparse allocations. However, I do not support: 1. unrestricted issuance of /29s to every organization regardless of needs. 2. Use of /29s where /28s can be issued. I am familiar with Dean's arguments, and he and I have agreed to disagree in the past many times. Owen On Sep 16, 2014, at 5:26 PM, 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. There are changes to section 4. Proposed policy solution only. 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 change 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-v004 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 multiple /32, they can announce these blocks and its reachability will be better than longer prefix. - If an LIR needs address blocks larger than /32, LIRs may tend to announce as a single prefix if a /29 is allocated initially at once. i.e., total number of announced prefixes in case 1 may be smaller than in case 2. case 1: The LIR obtains /29 at the beginning of IPv6 network construction. case 2: The LIR obtains /32, and /31, /30 additionally with the subsequent allocation mechanism. 2. Objective of policy change - This proposal modifies the eligibility for an organization to receive or extend an IPv6 address space up to a /29 (/32 -/29) by explaining how the extended space up to /29 will be used. 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 - Change the text to 5.2.2 Minimum initial allocation size of current policy document as below: Organizations that
