Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy [SECURITY=UNCLASSIFIED]

[Henderson Mike, Mr]

Not supported

The proposal should in my opinion be amended to read:
___

Disadvantages:



None Completely negates the purpose of prop-116-v006: Prohibit to transfer IPv4 
addresses in

the final /8 block.
___


Regards


Mike

From: sig-policy-boun...@lists.apnic.net 
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Bertrand Cherrier
Sent: Friday, 26 January 2018 4:28 p.m.
To: sig-pol...@apnic.net
Subject: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy

Dear SIG members,

The proposal "prop-123-v001: Modify 103/8 IPv4 transfer policy" has
been sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 45 in
Kathmandu, Nepal on Tuesday, 27 February 2018.

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-123

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

https://www.apnic.net/wp-content/uploads/2018/01/prop-123-v001.txt


---



prop-123-v001: Modify 103/8 IPv4 transfer policy



---



Proposer:Alex Yang

 yang...@126.com





1. Problem statement

---



Policy Proposal prop-116-v006: Prohibit to transfer IPv4 addresses in

the final /8 block reached consensus at the APNIC 44 AMM on 14 Sep

2017. Since that APNIC has stopped all the IPv4 transfers from 103/8

block if the delegation date is less than 5 years.



However, some of the 103/8 ranges were delegated before 14 Sep 2017.

Those resources should not be subjected to 5 years restriction. The

community was not aware of the restriction when they received those

resources, some of the resources have been transferred or planning to

transfer. If APNIC is not allow those transfers to be registered,

there will be underground transfers. This will cause incorrect APNIC

Whois data.





2. Objective of policy change

---



To keep the APNIC Whois data correct.





3. Situation in other regions

---



No such situation in other regions.





4. Proposed policy solution

---



“Prohibit transfer IPv4 addresses under final /8 address block (103/8)

which have not passed five years after its allocation/assignment”

should only apply to those ranges were delegated from APNIC since 14

Sep 2017.





5. Advantages / Disadvantages

---



Advantages:



- Allow APNIC to register those 103/8 transfers to keep the APNIC

  Whois data correct.





Disadvantages:



None.





6. Impact on resource holders

---



Resource holders are allowed to transfer 103/8 ranges if the resources

were delegated before 14 Sep 2017.







7. References

---

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

Re: [sig-policy] Revised prop-116-v003: Prohibit to transfer IPv4 addresses in the final /8 block [SECURITY=UNCLASSIFIED]

[HENDERSON MIKE, MR]

Folks,

I have said it before, and I’m afraid I will have to say it again after this, 
but
I do not support any further changes to IPv4 policy.

So far as I am concerned, this patient should have “Do Not Resuscitate” marked 
in big letters on its record card, and probably tattooed across its chest too

The worse the “IPv4 Problem” gets, the more pressure to roll out IPv6 and to 
address the practical issues with really big scale IPv6 deployments.


Regards


Mike

From: sig-policy-boun...@lists.apnic.net 
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Sumon Ahmed Sabir
Sent: Monday, 30 January 2017 12:39 a.m.
To: sig-pol...@apnic.net
Subject: [sig-policy] Revised prop-116-v003: Prohibit to transfer IPv4 
addresses in the final /8 block

Dear SIG members

A new version of the proposal "prop-116: Prohibit to transfer IPv4
addresses in the final /8 block" has been sent to the Policy SIG for
review.

Information about earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-116

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,

Masato and Sumon






---

prop-116-v003: Prohibit to transfer IPv4 addresses in the final /8 block

---

Proposer:   Tomohiro Fujisaki
fujis...@syce.net


1. Problem statement


There are a lot of transfers of IPv4 address blocks from 103/8
happening, both within the APNIC region and among RIRs.

Then number of transfer from 103/8 block are about 200, which is
about 12% of the total number of transfers. This looks so high
since APNIC manages about 40/8.

And based on the information provided by APNIC secretariat, number
of transfers from the 103/8 block are increasing year by year.

Updated by APNIC Secretariat on 27 January 2017:

1) M transfers containing 103/8 space

+--+---+---+-
|  |   Total   | Number of |
| Year | Transfers |   /24s|
+--+---+---+-
| 2011 | 3 | 12 |
| 2012 |10 | 46 |
| 2013 |18 | 66 |
| 2014 |   126 |498 |
| 2015 |   147 |573 |
| 2016 |63 |239 |
+--+---++-

2) Market transfers containing 103/8 space

+--+---+---+
|  |   Total   | Number of |
| Year | Transfers |   /24s|
+--+---+---+
| 2011 | 2 | 2 |
| 2012 |21 |68 |
| 2013 |16 |61 |
| 2014 |25 |95 |
| 2015 |67 |   266 |
| 2016 |   103 |   394 |
+--+---+---+

And also, transfers from the 103/8 block include:
  - Take place within 1 year of distribution, or
  - Multiple blocks to a single organization in case of beyond 1 year.

Further, there is a case where a single organization have received 12
blocks transfers from 103 range.

see:  https://www.apnic.net/transfer-resources/transfer-logs

From these figures, it is quite likely that substantial number of 103/8
blocks are being used for transfer purpose.

This conflicts with the concept of distribution of 103/8 block
(prop-062), which is intended to accommodate minimum IPv4 address blocks
for new comers.

°°prop-062: Use of final /8
°°https://www.apnic.net/policy/proposals/prop-062


2. Objective of policy change
-

When stated problem is solved, distribution from 103/8 block will be
consistent with its original purpose, for distribution for new entrants
to the industry. Without the policy change, substantial portion of 103/8
blocks will be consumed for transfer purpose.


3. Situation in other regions
-

None.


4. Proposed policy solution
---

Prohibit transfer IPv4 addresses under /8 address block (103/8) which
have not passed two years after its allocation/assignment.
If the address block allocated to a LIR in two years is not needed any
more, it must return to APNIC to allocate to another organization
using final /8 policy.

In the case of transfers due to M, merged organization can have
up to /22 IPv4 address in the 103/8 block in principle. If there
are technical reasons such as all address is used in separate networks
and announced from multiple ASes, merged organization can keep them.
Otherwise, the 103/8 IPv4 address more than /22 must return to APNIC
to allocate to another organization using final /8 policy.


5. Advantages / Disadvantages
-

Advantages:
  - It makes 103/8 blocks available according to the original purpose,
as distribution for new entrants (rather than being consumed for

Re: [sig-policy] New version of prop-116: Prohibit to transfer IPv4 addresses in the final /8 block (SECURITY=UNCLASSIFIED)

[HENDERSON MIKE, MR]

The objectives of this proposal are laudable, but in my view policy development 
for IPv4 is just ‘rearranging the deck chairs on the Titanic’: a waste of time 
and effort.


I do not support this proposal


Regards


Mike

From: sig-policy-boun...@lists.apnic.net 
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Masato Yamanishi
Sent: Monday, 26 September 2016 11:06 p.m.
To: sig-policy@lists.apnic.net
Subject: [sig-policy] New version of prop-116: Prohibit to transfer IPv4 
addresses in the final /8 block

Dear SIG members

A new version of the proposal "prop-116: Prohibit to transfer IPv4
addresses in the final /8 block" has been sent to the Policy SIG for
review.

Information about earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-116

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,

Masato, Sumon

---

prop-116-v002: Prohibit to transfer IPv4 addresses in the final /8 block

---

Proposer:   Tomohiro Fujisaki
fujis...@syce.net




1. Problem statement


There are a lot of transfers of IPv4 address blocks from 103/8
happening, both within the APNIC region and among RIRs.

Then number of transfer from 103/8 block are about 200, which is
about 12% of the total number of transfers. This looks so hight
high, since APNIC manages about 40/8.

And based on the information provided by APNIC secretariat, number
of transfers from the 103/8 block are increasing year by year.

Provided by George Kuo on the sig-policy ML at 8th September 2016:

1) M transfers containing 103/8 space

+--+---+---+-
|  |   Total   | Number of |
| Year | Transfers |   /24s|
+--+---+---+-
| 2011 | 3 | 12 |
| 2012 |10 | 46 |
| 2013 |18 | 66 |
| 2014 |   126 |498 |
| 2015 |   147 |573 |
| 2016 |45 |177 |
+--+---++-

2) Market transfers containing 103/8 space

+--+---+---+
|  |   Total   | Number of |
| Year | Transfers |   /24s|
+--+---+---+
| 2011 | 2 | 2 |
| 2012 |21 |68 |
| 2013 |16 |61 |
| 2014 |25 |95 |
| 2015 |67 |   266 |
| 2016 |56 |   206 |
+--+---+---+


And also, transfers from the 103/8 block include:
  - Take place within 1 year of distribution, or
  - Multiple blocks to a single organization in case of beyond 1 year.

Further, there is a case where a single organization have received 12
blocks transfers from 103 range.

see:  https://www.apnic.net/transfer-resources/transfer-logs

From these figures, it is quite likely that substantial number of 103/8
blocks are being used for transfer purpose.

This conflicts with the concept of distribution of 103/8 block
(prop-062), which is intended to accommodate minimum IPv4 address blocks
for new comers.

　prop-062: Use of final /8
　https://www.apnic.net/policy/proposals/prop-062


2. Objective of policy change
-

When stated problem is solved, distribution from 103/8 block will be
consistent with its original purpose, for distribution for new entrants
to the industry. Without the policy change, substantial portion of 103/8
blocks will be consumed for transfer purpose.


3. Situation in other regions
-

RIPE-NCC has been discussing to prohibit transfer under the final /8
address block.


4. Proposed policy solution
---

Prohibit transfer IPv4 address under /8 address block (103/8).
If the address block allocated to a LIR is not needed any more, it have
to return to APNIC to allocate to another organization.

In the case of transfers due to M, merged organization can have
up to /22 IPv4 address in the 103/8 block. The 103/8 IPv4 address
more than /22  have to return to APNIC to allocate to another
organization.


5. Advantages / Disadvantages
-

Advantages:
  - It makes 103/8 blocks available according to the original purpose,
as distribution for new entrants (rather than being consumed for
transfer purpose)

  - IPv4 addresses under final /8 are not transferred to outside APNIC.

  - By prohibiting transfer them, it is possible to keep one /22 for
each LIRs state,  which is fair for all LIRs.

Disadvantages:

None.


6. Impact on resource holders
--

  - LIRs cannot transfer address blocks under 103/8. No big impact while
they use it.

  - Organizations which needs to receive 

Re: [sig-policy] New Policy Proposal prop-116: Prohibit to transfer IPv4 addresses in the final /8 block [SECURITY=UNCLASSIFIED]

[HENDERSON MIKE, MR]

“Or.. Just get over with it :)”
+1

I think spending time and effort on IPv4 policy is just purposeless.
Realistically, the people who are commercially wedded to that platform will do 
whatever it takes to keep afloat for as long as they can. Trying to make IPv4 
Policy ‘work right’ will be like playing “Whack-a-Mole” as the desperate 
players display every bit of ingenuity and rat cunning they possess to stay in 
the game, until their business model eventually becomes untenable.



Regards


Mike

From: sig-policy-boun...@lists.apnic.net 
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Aftab Siddiqui
Sent: Wednesday, 21 September 2016 12:55 p.m.
To: Yuya KAWAKAMI; sig-policy@lists.apnic.net
Subject: Re: [sig-policy] New Policy Proposal prop-116: Prohibit to transfer 
IPv4 addresses in the final /8 block

prop-116 is similar to prop-106 with few cosmetic changes so it would be good 
to review the old discussion.

I wonder if there can be better way to prevent such kind of transfer.

Yes, there is a better way, scrap prop-105 and stop handing over additional /22 
for no reason and add the recovered resources to final /8 pool. Or.. Just get 
over with it :)
--
Best Wishes,

Aftab A. Siddiqui

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

Re: [sig-policy] APNIC Whois Database Accuracy [SECURITY=UNCLASSIFIED]

[HENDERSON MIKE, MR]

So, out of about 6400 members, we get over 1200 billing address bounces per 
annum?
Close to 20% have the single most basic piece of information* wrong?
Wow!
☹


Regards


Mike
*  “the single most basic piece of information” from a service provider’s point 
of view has to be ‘who do I send the bill to?’

From: sig-policy-boun...@lists.apnic.net 
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Adam Gosling
Sent: Thursday, 30 June 2016 11:29 a.m.
To: Aftab Siddiqui; Policy Mailing List
Subject: Re: [sig-policy] APNIC Whois Database Accuracy

Hello Aftab, all

The Services and Finance teams have helped us out with the following data as 
you requested. I’ll reply in-line.


On 27/06/2016, 18:43, 
"sig-policy-boun...@lists.apnic.net 
on behalf of Aftab Siddiqui" 
 
on behalf of aftab.siddi...@gmail.com> wrote:

Hi Adam/Secretariat,

Just to get more information.

Can you please share the following stats.



- how many request APNIC received in last 12 months to correct the whois record?

In the last 12 months we have received 1,329 reports of invalid Whois contacts.



- how many active myapnic accounts we have as compare to total numbers of 
active APNIC members. Assuming 1 myapnic account = 1 member?

We have a total of 6401 active Member and Non-Member accounts. Of them 5839 
have MyAPNIC access. This would not include NIR accounts.



- how many members have not created IRT object yet?

At APNIC 38 we reported that 87% of accounts had registered an IRT contact 
object. Following that we did some work as part of the Whois Data Quality 
Improvement project and can now report that 96% of accounts now have IRT 
objects. This leaves about 260 without and we will look into why that is.

These numbers are based on MyAPNIC activity. Some may have registered via email 
– that would be a small number, if any.



- how many emails bounce back from billing contacts (just an average per month)?

Finance Department reports that on average we get around 100 to 110 bounces 
each month from billing contacts.



I hope this data helps. Please feel comfortable to ask for any other 
information you need. We will do our best to provide what you need.

Regards

Adam


___
Adam Gosling
Internet Policy Development Consultant, APNIC
e: a...@apnic.net
p: +61 7 3858 3142
m: +61 421 456 243
t: @bout_policy
___

Join the conversation:   https://blog.apnic.net/
___



On Tue, 21 Jun 2016 at 16:53 Jahangir Hossain 
> wrote:
Thanks Aftab for your comments and information .
We already know the importance of  Whois database accuracy specially the 
exchange of information for cyber security mitigation . if community have mixed 
comments then we can execute this as pilot project specially on IRT object or 
single country .


Regards / Jahangir

On Tue, Jun 21, 2016 at 12:21 PM, Aftab Siddiqui 
> wrote:
I also support Gaurab’s idea to tag the authoritative of account holder. 
Besides i would like to add one point with Gaurab's idea ; Can we send 
verification message through mail to account holder's corporate and technical 
contact person by quarterly/half a year/yearly basis?

if one of the contact person is not verify this information then account 
accessibility will be disable . Other wise it's really hard to make more 
reliable and accurate whois database that we are thinking .

+0.5

I've been proposing this for years now (earlier in Network abuse BoF) and 
recently did it in policy-sig and there was very mixed response. ARIN has this 
policy but as per Leslie Noble (ARIN) it is not very successful in their region 
but she also mentioned that they are planning to make few changes in the 
process (need to reach out to her again for the update).

For those who were not present there.. here is the transcript link
https://conference.apnic.net/data/41/20160225-Policy-SIG-2.txt
(hint: search my name)

--
Best Wishes,

Aftab A. Siddiqui


--

--
Best Wishes,

Aftab A. Siddiqui

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

Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]

[HENDERSON MIKE, MR]

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] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

[HENDERSON MIKE, MR]

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] New version of prop-111: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

[HENDERSON MIKE, MR]

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] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

[HENDERSON MIKE, MR]

+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