Orbit

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 dean@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.HENDERSON@nzdf.mil.nz mailto:MICHAEL.HENDERSON@nzdf.mil.nz> wrote: I agree with Owen

Regards

Mike

From: sig-policy-bounces@lists.apnic.net <> [mailto:sig-policy-bounces@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 <myamanis@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 fujisaki@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:0000::/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 <http://www.apnic.net/policy/ipv6-address-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 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.

--

Dean Pemberton

Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz mailto:dean@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.

•          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 http://mailman.apnic.net/mailman/listinfo/sig-policy

https://www.mls.nc/ Bertrand Cherrier, Administrateur Systèmes b.cherrier@micrologic.nc mailto:b.cherrier@micrologic.nc www.mls.nc https://www.mls.nc/ @micrologicnc http://twitter.com/micrologicnc Sur facebook https://www.facebook.com/mls.nc Téléphone: 24 99 24 VoIP: 65 24 99 24 Service Clientèle: 36 67 76 (58F/min)

On Feb 3, 2015, at 8:12 PM, Robert Hudson hudrob@gmail.com wrote:

On 4 February 2015 at 14:54, Dean Pemberton <dean@internetnz.net.nz mailto:dean@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

Dear Colleagues,

Regarding prop-112,

1. Dean Pemberton summarized concerns for this proposal

http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00020.h...

2. Robert Hudson claimed that the benefit (utilizing dead space) is larger than the concern

http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00023.h...

3. Owen DeLong is against for the benefit he proposed alternative solution (giving another /28 and wait)

http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00033.h... Mike Henderson support this alternative. (I believe, Sanjeev Gupta will also support, but correct me if different)

So, I would like to ask your views for following questions.

Q1. Is the benefit larger than the concern or not? Q2. Does the alternative solution proposed by Owen resolve this problem also?

Tomohiro> Can you express your view as original author for 2nd point?

Regards, Masato Yamanishi, Policy SIG Chair (Acting)

2015-02-04 10:26 GMT-06:00 Owen DeLong owen@delong.com:

On Feb 3, 2015, at 8:12 PM, Robert Hudson hudrob@gmail.com wrote:

On 4 February 2015 at 14:54, Dean Pemberton dean@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

On Feb 23, 2015, at 13:00 , Dean Pemberton dean@internetnz.net.nz wrote:

On Tue, Feb 24, 2015 at 7:13 AM, Masato Yamanishi myamanis@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

+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.

I would like to see RIR allocations and assignments done on nibble boundaries.

Owen

On 25 February 2015 at 07:13, Dean Pemberton dean@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.

Dear all,

Thank you so much for your feedback on prop-112, and I'm sorry for not to reply soon.

Again, main objective of prop-112 is to utilize reserved IPv6 address in 'legacy' block. Legacy blocks are: 2001:0200::/23, 2001:0c00::/23, 2001:0e00::/23 and 2001:4400::/23. Here is current usage information of these blocks.

Block # of /32 # of < /32 Reserved ----------------------------------------------------------- 2001:0200::/23 62 0 84.8% 2001:0c00::/23 56 1 76.6% 2001:0e00::/23 61 1 83.4% 2001:4400::/23 30 5 41.0% (used for /48 assignment etc.)

RIPE-NCC has same kind of legacy blocks and their usage information is:

Block # of /32 # of /29 Reserved ----------------------------------------------------------- 2001:600::/23 46 16 62.9% 2001:800::/23 45 16 61.5% 2001:a00::/23 47 13 64.3% 2001:1400::/23 54 6 73.8% 2001:1600::/23 22 8 30.1% 2001:1a00::/23 50 14 68.4% 2001:4000::/23 53 7 72.5% 2001:4a00::/23 24 8 32.8% 2001:4c00::/23 52 9 71.1%

It looks that RIPE-NCC has utilized reserved address blocks in legacy space. I suppose this is because they have implemented a policy that allow to distribute up to /29 IPv6 address space.

And one point, some legacy space holders in APNIC have obtained larger address blocks than /29.

I think we need to any take action to utilize these reserved space.

-- Tomohiro Fujisaki

From: Masato Yamanishi myamanis@gmail.com Subject: Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED] Date: Mon, 23 Feb 2015 12:13:10 -0600

| Dear Colleagues, | | Regarding prop-112, | | 1. Dean Pemberton summarized concerns for this proposal | | http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00020.h... | | 2. Robert Hudson claimed that the benefit (utilizing dead space) is larger | than the concern | | http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00023.h... | | 3. Owen DeLong is against for the benefit he proposed alternative solution | (giving another /28 and wait) | | http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00033.h... | Mike Henderson support this alternative. (I believe, Sanjeev Gupta will | also support, but correct me if different) | | So, I would like to ask your views for following questions. | | Q1. Is the benefit larger than the concern or not? | Q2. Does the alternative solution proposed by Owen resolve this problem | also? | | Tomohiro> Can you express your view as original author for 2nd point? | | Regards, | Masato Yamanishi, Policy SIG Chair (Acting) | | | | 2015-02-04 10:26 GMT-06:00 Owen DeLong owen@delong.com: | | > | > On Feb 3, 2015, at 8:12 PM, Robert Hudson hudrob@gmail.com wrote: | > | > On 4 February 2015 at 14:54, Dean Pemberton dean@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 | > | >

Hi Dean,

Thank you for your comment.

From: Dean Pemberton dean@internetnz.net.nz Subject: Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED] Date: Wed, 4 Feb 2015 16:54:36 +1300

| There are a number of things that concern me about this proposal. | | 1) it doesn't appear to support needs based allocation

I think it will be covered by the fee schedule. And also, the space is reserved for the organizing, and will be unused in the future.

| 2) it doesn't support allocation on nibble boundaries which operators have | said repeatedly is a major issue.

Yes, however,

1) Current policy do not care about nibble boundaries when address holders expand their address space. Non-nibble boundary address will be allocated in all case of address space expantion.

2) Cannot expand to /28 in legacy space.

And this is not discussion point here, but I think:

3) Technically, nibble boundaries will be reasonable, however, too much IPv6 address space will be allocated if nibble boundary based allocation is introduced. (/32 -> /28 -> /24 ...)

Yours Sincerely, -- Tomohiro Fujisaki