Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
Dear SIG members,
The proposal, 'Distribution of IPv4 addresses once the final /8 period starts', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 29 in Kuala Lumpur, 21-25 February 2011.
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 and other policy proposals is available from:
http://www.apnic.net/policy/proposals
Gaurab, Ching-Heng, and Terence
________________________________________________________________________
prop-088-v001: Distribution of IPv4 addresses once the final /8 period starts ________________________________________________________________________
Author: Randy Bush randy@psg.com
Philip Smith pfs@cisco.com
Version: 1
Date: 22 November 2010
1. Introduction ----------------
This is a proposal to handle any IPv4 address space received by APNIC after the final /8 policy is implemented as being part of the final /8 pool and to redistribute these resources according to the final /8 policies.
2. Summary of current problem ------------------------------
After APNIC has activated the "final /8" allocation policies[1], there is the possibility that APNIC will receive further IPv4 addresses. These IPv4 addresses will come either directly from Asia Pacific networks that no longer need them, or, if the global policy proposal for redistributing resources from the IANA succeeds, from the IANA.
The intent of the authors of the original final /8 policy proposal was to have all other IPv4 allocation and assignment policies replaced by the delegation policy described in the final /8 policy. However, the current language of the final /8 policy does not explicitly repeal the other IPv4 allocation and assignment policies. The authors are therefore aware that there may be some confusion as to how such returned addresses should be distributed by APNIC. This proposal seeks to clarify the situation.
3. Situation in other RIRs ---------------------------
There is no similar policy or proposal in other regions.
4. Details of the proposal ---------------------------
It is proposed that:
4.1 When APNIC has distributed all other available IPv4 resources, and has to start distributing from the final /8, any IPv4 resources received after that point will be placed into the final /8 pool.
- This placement into the final /8 pool will occur even if the result is a pool larger than one /8.
- Subject to any future global policy for the redistribution of addresses received by the IANA from the RIRs (for example, prop-069), this placement applies to any IPv4 addresses APNIC receives from:
- the IANA; and/or - holders of addresses in the APNIC Whois Database
4.2 These resources received in 4.1 are to be distributed according to the same policies as apply to the final /8 [1].
5. Advantages and disadvantages of the proposal ------------------------------------------------
5.1 Advantages
- It reduces confusion possible if IPv4 resources are received outside the final /8 but during the period when the final /8 policy is active by explicitly stating how these IPv4 resources are to be handled.
5.2 Disadvantages
- No disadvantages are foreseen.
6. Effect on APNIC members ---------------------------
APNIC members can only request and receive a single distribution from the final /8. This would also apply to any other IPv4 addresses placed in the final /8 pool by this policy.
7. Effect on NIRs ------------------
This will affect NIR members in the same way as APNIC members.
8. References --------------
[1] Section 9.10 "Distribution of the final /8 worth of space in the unallocated APNIC IPv4 address pool" of "Policies for IPv4 address space management in the Asia Pacific region" http://www.apnic.net/policy/add-manage-policy#9.10 _______________________________________________
Terence, thank you for that. If enacted, it does, indeed, reduce some of the APNIC specific aspects of external concerns.
However, it does raise new ones.
By placing all such addresses into the post-exhaustion pool with its very restrictive policies for allocation/assignment, you create the situation where:
1. APNIC is unlikely to receive additional space from IANA as they are unlikely to exhaust the pool as defined in the proposed global policy.
2. Once all current APNIC resource holders have received their single /22 from this pool, the pool could become a monotonically increasing collection of addresses that cannot be utilized. Of course, the workaround for this is to merely create an additional APNIC org each time you want to receive a /22.
The second concern is actually somewhat valid even with the existing policy, but, certainly if there is the ability for this pool to grow from external addresses, I suspect it will become a more tempting target.
Owen
On Nov 23, 2010, at 2:09 PM, Owen DeLong wrote:
By placing all such addresses into the post-exhaustion pool with its very restrictive policies for allocation/assignment, you create the situation where:
- APNIC is unlikely to receive additional space from IANA as they are unlikely to exhaust the pool as defined in the proposed global policy.
Valid concern, though at that point I'd argue that new LIRs in the APNIC region are still better off in that they are guaranteed an allocation from the final /8, irrespective of the timing of the RIR obtaining 'new' space from IANA and the timings of other lIRs requesting new space.
- Once all current APNIC resource holders have received their single /22 from this pool, the pool could become a monotonically increasing collection of addresses that cannot be utilized.
...under current policy.
The intent of the final /8 policy is to have a very conservative allocation policy that allows every single LIR one last piece of the pie. Allocation policy can be fine tuned (loosened up) for this last /8 at a later date if required. Seems a prudent approach to me.
Of course, the workaround for this is to merely create an additional APNIC org each time you want to receive a /22.
The second concern is actually somewhat valid even with the existing policy, but, certainly if there is the ability for this pool to grow from external addresses, I suspect it will become a more tempting target.
Given the size of the last /8 compared to the current number (and anticipated growth) of LIRs, I think the temptation is already there and won't be increased due to additional returned space.
I support prop-88 as written.
Cheers, Jonny.
Hi Owen,
Thanks for your comments! Yes, the goal of this proposal was to address the concerns mentioned at the previous APNIC meeting.
Owen DeLong said the following on 23/11/10 13:09 :
- APNIC is unlikely to receive additional space from IANA as they are unlikely to exhaust the pool as defined in the proposed global policy.
Given the proposal you mention is just that, a proposal, prop-088 is written based on the current situation.
- Once all current APNIC resource holders have received their single /22 from this pool, the pool could become a monotonically increasing collection of addresses that cannot be utilized. Of course, the workaround for this is to merely create an additional APNIC org each time you want to receive a /22.
Creating additional orgs to get more resources is not a problem unique to the APNIC service region either. Been discussed many times already.
Yes, the "final /8" pool size could increase, but no one knows by how much it will increase. Plus there is nothing in prop-088 stopping a future policy proposal changing the delegation from /22 to something larger if the desire arises.
Hope this helps...
philip --
On Nov 24, 2010, at 2:32 AM, Philip Smith wrote:
Hi Owen,
Thanks for your comments! Yes, the goal of this proposal was to address the concerns mentioned at the previous APNIC meeting.
Owen DeLong said the following on 23/11/10 13:09 :
- APNIC is unlikely to receive additional space from IANA as they are unlikely to exhaust the pool as defined in the proposed global policy.
Given the proposal you mention is just that, a proposal, prop-088 is written based on the current situation.
Sure. However, if it becomes policy it will outlive the current situation and should be considered in light of both the current situation and likely future scenarios.
- Once all current APNIC resource holders have received their single /22 from this pool, the pool could become a monotonically increasing collection of addresses that cannot be utilized. Of course, the workaround for this is to merely create an additional APNIC org each time you want to receive a /22.
Creating additional orgs to get more resources is not a problem unique to the APNIC service region either. Been discussed many times already.
True, but, the one last slice policy is, to the best of my knowledge, unique to APNIC. Others have policies along the lines of one slice per x time period.
This provides significantly greater incentive for synthetic orgs in the APNIC region than in others, IMHO.
Owen
Owen raises a reasonable concern about the possibility of extra addresses being added to the final /8 pool and us finding ourselves with a pool of addresses that is increasing if we adopt this proposal.
I believe that while this is a possibility it's not that likely an event. I'm not convinced that we will see large blocks of address space returned to IANA and the RIRs - I suspect that we're much more likely to see addresses exchanged on the open market.
If we do see the address pool held by APNIC growing because of returned addresses then I think we should address the issue at that time and this policy should be adopted now.
Good policy should encourage good behaviour and making it very clear to people that when we get into the final /8 that there will be one /22 each encourages people to get on with adding IPv6 to their networks instead of hoping the some hypothetical return of addresses will save them.
I believe it is APNIC's duty to distribute addresses in order to meet any valid need to connect users in the Asia-Pacific region to the Internet, for as long as APNIC has addresses to distribute. If APNIC withholds any addresses it has from the Asia-Pacific community when there is a demonstrated demand for those addresses, then to my mind it is not fulfilling this duty.
There are 16,384 /22s in a /8. As discussed during the debate on prop-062, it seems unlikely that APNIC membership would achieve even 8,000 account holders for many years yet - by when we all hope that there will be no further demand for IPv4.
This means that under the Final /8 policy that more than a /9 is likely to remain permanently withheld from the general Internet community for no apparent purpose - not even for the stated reason of the policy to provide a pool for new LIRs for transition purposes. In other words, over 8 million users (or more if NATed) who could be Internet connected with IPv4 addresses during 2012 (when they will be most needed) will be denied that opportunity because of the Final /8 policy.
Prop-088 would seem only to exacerbate this situation. I do not personally expect that many addresses will be provided to APNIC after the final IANA allocation, but I cannot support the principle of this proposal that any recovered addresses should be effectively withheld from further reuse in the Internet community.
(At least, not until such a time that the IETF might formally state that the use of IPv4 is deprecated and further distribution of IPv4 addresses should cease - I believe that it is an IETF role (and not APNIC's) to make decisions about the overall status of an entire address space.)
I therefore do not support this proposal.
Regards,
David Woodgate
So slightly off-topic.
On 26/11/2010, at 3:39 PM, David Woodgate wrote:
I believe it is APNIC's duty to distribute addresses in order to meet any valid need to connect users in the Asia-Pacific region to the Internet, for as long as APNIC has addresses to distribute. If APNIC withholds any addresses it has from the Asia-Pacific community when there is a demonstrated demand for those addresses, then to my mind it is not fulfilling this duty.
Fully agree. And in thinking about this I asked myself the question "what does APNIC have in its reserves?" I tried to find something on 'apstats' but there didn't seem anything obvious. Can someone point me to the list of unallocated and(or) reserved/reclaimed resources that APNIC and its NIRs have?
If such a thing doesn't yet exist can something please be created?
Perhaps following (and extending) the rir statistics exchange format?
http://www.apnic.net/publications/media-library/documents/resource-guideline...
Cheers Terry
Hi,
For a list of addresses in the APNIC pool, see http://bgp.potaroo.net/ipv4-stats/prefixes_apnic_pool.txt
There are lots of other useful files linked from the bottom of http://www.potaroo.net/tools/ipv4/index.html , my favorites being http://www.potaroo.net/bgp/ipv4-stats/allocated-all.html and http://bgp.potaroo.net/ipv4-stats/prefixes.txt
I don't know of any list of "reserved addresses" addresses like --- $ whois 1.0.0.0 % [whois.apnic.net node-3] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 1.0.0.0 - 1.0.0.255 netname: Debogon-prefix descr: APNIC Debogon Project descr: APNIC Pty Ltd ... ---
John
On Wed, Dec 1, 2010 at 11:48 AM, Terry Manderson terry@terrym.net wrote:
So slightly off-topic.
On 26/11/2010, at 3:39 PM, David Woodgate wrote:
I believe it is APNIC's duty to distribute addresses in order to meet any valid need to connect users in the Asia-Pacific region to the Internet, for as long as APNIC has addresses to distribute. If APNIC withholds any addresses it has from the Asia-Pacific community when there is a demonstrated demand for those addresses, then to my mind it is not fulfilling this duty.
Fully agree. And in thinking about this I asked myself the question "what does APNIC have in its reserves?" I tried to find something on 'apstats' but there didn't seem anything obvious. Can someone point me to the list of unallocated and(or) reserved/reclaimed resources that APNIC and its NIRs have?
If such a thing doesn't yet exist can something please be created?
Perhaps following (and extending) the rir statistics exchange format?
http://www.apnic.net/publications/media-library/documents/resource-guideline...
Cheers Terry
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 John,
On 01/12/2010, at 12:52 PM, John Mann (ITS) wrote:
Hi,
For a list of addresses in the APNIC pool, see http://bgp.potaroo.net/ipv4-stats/prefixes_apnic_pool.txt
That looks like its just the addresses that have been allocated by APNIC - which can be easily found from their authoritative source:
ftp://ftp.apnic.net/apnic/stats/apnic/
while Geoff runs potaroo, and Geoff works for APNIC, potaroo is not APNIC. His (Geoff's potaroo) information is insightful, but ultimately not authoritative.
[..]
I don't know of any list of "reserved addresses" addresses like
At the APNIC meeting and at AusNOG the APNIC secretariat presented a process (resource quality assurance) of how addresses are 'processed' to then be allocated. Which to me means that there will be some pool of resources in various states of process. Be that from new IANA /8s or reclaimed/returned addresses.
I think it is hugely useful to know this information. Just like we have had a complete registry from IANA for many years detailing what is allocated, what is reserved and so on. I don't want to infer it by doing a inverse of the APNIC allocations, I would like the authoritative list from APNIC and the NIRs.
Clearly the final /8 is near, but that isn't the end of IPv4.
Cheers Terry
On Wed, Dec 1, 2010 at 2:26 PM, Terry Manderson terry@terrym.net wrote:
Hi John,
On 01/12/2010, at 12:52 PM, John Mann (ITS) wrote:
Hi,
For a list of addresses in the APNIC pool, see
http://bgp.potaroo.net/ipv4-stats/prefixes_apnic_pool.txt
That looks like its just the addresses that have been allocated by APNIC - which can be easily found from their authoritative source:
ftp://ftp.apnic.net/apnic/stats/apnic/ ...
The prefixes_apnic_pool.txt file _is_ a list of free addresses in the pool. It is _not_ a list of addresses that have been allocated by APNIC. The first entry is "1.0.1.0/24"
Do you know which file on the APNIC site contains the free pool list? i.e. which file contains an entry of "1.0.1.0/24"
John
On 02/12/2010, at 10:26 AM, John Mann (ITS) wrote:
The prefixes_apnic_pool.txt file _is_ a list of free addresses in the pool. It is _not_ a list of addresses that have been allocated by APNIC. The first entry is "1.0.1.0/24"
Ahh,... I see. thx for clarifying.
Do you know which file on the APNIC site contains the free pool list? i.e. which file contains an entry of "1.0.1.0/24"
Simply there isn't.. and that is, in my opinion, an issue. Potaroo has its uses, but it is not _the_ authoritative source.
Cheers Terry
Are the "various registries" that APNIC received from the IANA along with the other RIR's documented as well?
And thank you, APNIC, for the openness.
On 12/1/10 7:44 PM, "Terry Manderson" terry@terrym.net wrote:
On 02/12/2010, at 10:26 AM, John Mann (ITS) wrote:
The prefixes_apnic_pool.txt file _is_ a list of free addresses in the pool. It is _not_ a list of addresses that have been allocated by APNIC. The first entry is "1.0.1.0/24"
Ahh,... I see. thx for clarifying.
Do you know which file on the APNIC site contains the free pool list? i.e. which file contains an entry of "1.0.1.0/24"
Simply there isn't.. and that is, in my opinion, an issue. Potaroo has its uses, but it is not _the_ authoritative source.
Cheers Terry
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 John and all,
We don't currently publish the free pool list. While external sources can derive the free pool by comparing APNIC's IANA allocation vs APNIC delegation report, APNIC secretariat can actually produce a more detailed list of all resources in their different states such as delegated, reserved, returned, or available.
I'm interested to hear from the community:
1. Should APNIC produce a list? 2. What purpose does it serve? 3. What information should be there? Detailed prefix or totals? 4. What are the benefits and risks of showing such information? 5. What should the reporting frequency be?
Thanks, ________________________________________________________________________ Sanjaya email: sanjaya@apnic.net Services Director, APNIC sip: sanjaya@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________ * Sent by email to save paper. Print only if necessary.
On 2/12/2010 10:26 AM, John Mann (ITS) wrote:
The prefixes_apnic_pool.txt file _is_ a list of free addresses in the pool. It is _not_ a list of addresses that have been allocated by APNIC. The first entry is "1.0.1.0/24 http://1.0.1.0/24"
Do you know which file on the APNIC site contains the free pool list? i.e. which file contains an entry of "1.0.1.0/24 http://1.0.1.0/24"
John
On 02/12/2010, at 11:21 AM, Sanjaya wrote:
I'm interested to hear from the community:
speaking for myself.
- Should APNIC produce a list?
Most definitely
- What purpose does it serve?
full transparency of resources that APNIC is accountable for.
- What information should be there? Detailed prefix or totals?
detailed per prefix/address block/ASN block as per RIR stats.
- What are the benefits and risks of showing such information?
Benefits:
1) Community gets to see full state of APNIC and NIR resource pools, esp IPv4 states. This may or may not help IPv6 uptake. It might also provide a way that some policies can then be measured, or policy proposals can be evaluated.
2) APNIC can 'check' the registry data transparency box. :-)
3) while I'm not a fan of bogon lists, especially the type that don't get updated. An authoritative source might make creating such lists easier.
Risks:
I don't believe there are any. There might be an argument about hijacking resources, but really shouldn't that be addressed by RPKI? And since potaroo already has that 'inverse' list wouldn't bad people just use that?
So right now I can't think of any risks.
- What should the reporting frequency be?
Daily please.
Cheers Terry
Terry, we seem to post at the same time :) Thanks for this, let's now wait for other's views.
Cheers, Sanjaya
On 2/12/2010 11:48 AM, Terry Manderson wrote:
On 02/12/2010, at 11:21 AM, Sanjaya wrote:
I'm interested to hear from the community:
speaking for myself.
- Should APNIC produce a list?
Most definitely
- What purpose does it serve?
full transparency of resources that APNIC is accountable for.
- What information should be there? Detailed prefix or totals?
detailed per prefix/address block/ASN block as per RIR stats.
- What are the benefits and risks of showing such information?
Benefits:
Community gets to see full state of APNIC and NIR resource pools, esp IPv4 states. This may or may not help IPv6 uptake. It might also provide a way that some policies can then be measured, or policy proposals can be evaluated.
APNIC can 'check' the registry data transparency box. :-)
while I'm not a fan of bogon lists, especially the type that don't get updated. An authoritative source might make creating such lists easier.
Risks:
I don't believe there are any. There might be an argument about hijacking resources, but really shouldn't that be addressed by RPKI? And since potaroo already has that 'inverse' list wouldn't bad people just use that?
So right now I can't think of any risks.
- What should the reporting frequency be?
Daily please.
Cheers Terry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Sanjaya
(2010/12/02 10:21), Sanjaya wrote:
Hi John and all,
We don't currently publish the free pool list. While external sources can derive the free pool by comparing APNIC's IANA allocation vs APNIC delegation report, APNIC secretariat can actually produce a more detailed list of all resources in their different states such as delegated, reserved, returned, or available.
I'm interested to hear from the community:
- Should APNIC produce a list?
It would be interesting to see that list, but I don't have an immediate need for it.
- What purpose does it serve?
don't know for sure, since I don't have the need for it right now.
- What information should be there? Detailed prefix or totals?
My favor would be totals
- What are the benefits and risks of showing such information?
showing detailed prefix info may lead to usage like the 1.2.3.0/24 space, which people will do anyways without the list, but it might lower the hurdles of misuse. Having detailed information may be helpful to researchers or people who love stats, but I don't know how it would help LIRs. (clue bat please)
Showing the totals may help in letting everyone in the region know just how much there is left, which may be valuable info to people who are thinking about asking for an allocation and are considering when is the best time to do so. I don't see any risk here.
- What should the reporting frequency be?
don't know.
Regards, Seiichi
Thanks, ________________________________________________________________________ Sanjaya email: sanjaya@apnic.net Services Director, APNIC sip: sanjaya@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________
- Sent by email to save paper. Print only if necessary.
On 2/12/2010 10:26 AM, John Mann (ITS) wrote:
The prefixes_apnic_pool.txt file _is_ a list of free addresses in the pool. It is _not_ a list of addresses that have been allocated by APNIC. The first entry is "1.0.1.0/24 http://1.0.1.0/24"
Do you know which file on the APNIC site contains the free pool list? i.e. which file contains an entry of "1.0.1.0/24 http://1.0.1.0/24"
John
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
- Should APNIC produce a list?
don't care. have no use for it. save the time and money.
- What purpose does it serve?
fodder for mailing list noise?
- What information should be there? Detailed prefix or totals?
- What are the benefits and risks of showing such information?
- What should the reporting frequency be?
over the next years, it might be fun to have a bar graph of how much space is in the free pool by block size. run time over the z axis.
i have no actual need for it. but it might be cool looking. i am sure geoff would have brighter ideas and will make pretty pictures.
randy
Sanjaya
On Thu, Dec 2, 2010 at 12:21 PM, Sanjaya sanjaya@apnic.net wrote:
Hi John and all,
We don't currently publish the free pool list. While external sources can derive the free pool by comparing APNIC's IANA allocation vs APNIC delegation report, APNIC secretariat can actually produce a more detailed list of all resources in their different states such as delegated, reserved, returned, or available.
I'm interested to hear from the community:
- Should APNIC produce a list?
Yes.
- What purpose does it serve?
Data for research. Allows better understanding of the current state.
- What information should be there? Detailed prefix or totals?
At least the detailed prefixes.
Options: a) Publish an official version of Geoff's "prefixes_apnic_pool.txt" file.
b) Extend http://www.apnic.net/publications/media-library/documents/resource-guideline...
status Type of allocation from the set:
{allocated, assigned}
This is the allocation or assignment made by the registry producing the file and not any sub-assignment by other agencies.
Allow status to be (allocated, assigned, free, reserved, reclaimed)
c) Some other file in some other format, with e.g. a notes field that links to relevant policy, project descriptions etc, similar to http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt
Options a) and b) should only require a couple of extra lines of SQL, a few extra lines in cron, and job done.
4. What are the benefits and risks of showing such information?
Benefits: More-informed membership. Reduce confusion / uncertainty.
Showing how small and fragmented the free pool is, and how well it is being managed should help *me* push my organisation to fully support IPv6 sooner!
Risks: The "free" pool data is already derivable, so no increased risk. And "reserved", and "reclaimed" are just sub-types of "free" ??
[ Can we assume that there aren't any political secrets that we don't want to come out? ]
- What should the reporting frequency be?
Daily, as per other information.
Thanks, John
Addressing this separately as I tried to find a reference but couldn't.
I vaguely recall that the APNIC Debogon Project discovered a set of addresses that were far to 'dirty' and APNIC decided to exclude these from future allocation.
Surely those would be a suitable candidate to include in a RIR/NIR public registry of unallocated/reserved/RQA-status/etc??
I don't know of any list of "reserved addresses" addresses like
$ whois 1.0.0.0 % [whois.apnic.net node-3] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 1.0.0.0 - 1.0.0.255 netname: Debogon-prefix descr: APNIC Debogon Project descr: APNIC Pty Ltd ...
Cheers Terry (ps sorry for hijacking the prop-88 policy thread)
I'd also be interested in a full public accounting of all current address space regardless of it's state, reserved or otherwise.
Best,
-M<
On 11/30/10 10:37 PM, "Terry Manderson" terry@terrym.net wrote:
Addressing this separately as I tried to find a reference but couldn't.
I vaguely recall that the APNIC Debogon Project discovered a set of addresses that were far to 'dirty' and APNIC decided to exclude these from future allocation.
Surely those would be a suitable candidate to include in a RIR/NIR public registry of unallocated/reserved/RQA-status/etc??
I don't know of any list of "reserved addresses" addresses like
$ whois 1.0.0.0 % [whois.apnic.net node-3] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 1.0.0.0 - 1.0.0.255 netname: Debogon-prefix descr: APNIC Debogon Project descr: APNIC Pty Ltd ...
Cheers Terry (ps sorry for hijacking the prop-88 policy thread)
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 all,
At this stage, the total amount of reserved and reclaimed address space in APNIC accounts for 0.21 /8s and 0.14 /8s, respectively. These are part of a bigger unallocated pool available for distribution which is 3.67 /8 as of today.
While we have the ability to track our IPv4 stock level internally, we are still working on finalizing a public reporting format that meets the community needs. We'd like to hear more from you about how we can best do this, so please keep sending ideas to this list. We are monitoring this thread closely. Thanks.
________________________________________________________________________ Sanjaya email: sanjaya@apnic.net Services Director, APNIC sip: sanjaya@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________ * Sent by email to save paper. Print only if necessary.
On 1/12/2010 1:39 PM, Hannigan, Martin wrote:
I'd also be interested in a full public accounting of all current address space regardless of it's state, reserved or otherwise.
Best,
-M<
On 11/30/10 10:37 PM, "Terry Manderson"terry@terrym.net wrote:
Addressing this separately as I tried to find a reference but couldn't.
I vaguely recall that the APNIC Debogon Project discovered a set of addresses that were far to 'dirty' and APNIC decided to exclude these from future allocation.
Surely those would be a suitable candidate to include in a RIR/NIR public registry of unallocated/reserved/RQA-status/etc??
I don't know of any list of "reserved addresses" addresses like
$ whois 1.0.0.0 % [whois.apnic.net node-3] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 1.0.0.0 - 1.0.0.255 netname: Debogon-prefix descr: APNIC Debogon Project descr: APNIC Pty Ltd ...
Cheers Terry (ps sorry for hijacking the prop-88 policy thread)
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
Hi Sanjaya,
On 01/12/2010, at 5:08 PM, Sanjaya wrote:
While we have the ability to track our IPv4 stock level internally, we are still working on finalizing a public reporting format that meets the community needs.
"Still working"? I was unaware that a discussion paper or community feedback request was sent out. If this has or was done, my apologies and please provide a URL.
What is the currently held list of community needs?
We'd like to hear more from you about how we can best do this, so please keep sending ideas to this list. We are monitoring this thread closely. Thanks.
Currently not knowing what you have listed as 'community needs' I might be suggesting already considered options. But here goes.
All of the RIRs appear to participate in the RIR stats production as seen here:
ftp://ftp.apnic.net/apnic/stats/apnic/
and the description of the stats format here: http://www.apnic.net/publications/media-library/documents/resource-guideline...
So not wanting to reinvent the wheel completely.
Perhaps update the enumerated list of 'status' to include "reserved" and "unallocated". In the 'extensions' field provide more information about the reason for the reserved/unallocated status.
e.g. - RQA state - PDP outcome such the /16 in the final /8 (PROP-reference) - Targeted allocation such as critical infrastructure assignments - 'dirty' prefix due to debogon research - ..
The date field should reflect when any status, or extension 'state' (for RQA) changes.
It probably doesn't need to be said, but the IP resources _should_ be in efficient aggregated CIDR blocks where possible. (as opposed to non-cidr blocks) I'm happy for best effort...
I'm also leaning to a "pending" status - meaning that the resource block has been earmarked for something that does not yet fit into reserved or unallocated. And thus a meaningful description can be put into the extensions section. This makes sense if the earmarking lasts for more than one issuance of the stats file.
Cheers Terry
Hi Terry and all,
On 2/12/2010 11:21 AM, Terry Manderson wrote:
Hi Sanjaya,
On 01/12/2010, at 5:08 PM, Sanjaya wrote:
While we have the ability to track our IPv4 stock level internally, we are still working on finalizing a public reporting format that meets the community needs.
"Still working"? I was unaware that a discussion paper or community feedback request was sent out. If this has or was done, my apologies and please provide a URL.
It's a follow up to the Final stages of IPv4 distribution Guangliang presented in APNIC 30 Gold Coast. He explained the different states of APNIC resources.
http://meetings.apnic.net/30/program/plenary
What is the currently held list of community needs?
That we need to show the total resources in the different states, so we all know which Phase of the Final stages we are on.
We'd like to hear more from you about how we can best do this, so please keep sending ideas to this list. We are monitoring this thread closely. Thanks.
Currently not knowing what you have listed as 'community needs' I might be suggesting already considered options. But here goes.
All of the RIRs appear to participate in the RIR stats production as seen here:
ftp://ftp.apnic.net/apnic/stats/apnic/
and the description of the stats format here: http://www.apnic.net/publications/media-library/documents/resource-guideline...
So not wanting to reinvent the wheel completely.
Perhaps update the enumerated list of 'status' to include "reserved" and "unallocated". In the 'extensions' field provide more information about the reason for the reserved/unallocated status.
e.g.
- RQA state
- PDP outcome such the /16 in the final /8 (PROP-reference)
- Targeted allocation such as critical infrastructure assignments
- 'dirty' prefix due to debogon research
- ..
The date field should reflect when any status, or extension 'state' (for RQA) changes.
It probably doesn't need to be said, but the IP resources _should_ be in efficient aggregated CIDR blocks where possible. (as opposed to non-cidr blocks) I'm happy for best effort...
I'm also leaning to a "pending" status - meaning that the resource block has been earmarked for something that does not yet fit into reserved or unallocated. And thus a meaningful description can be put into the extensions section. This makes sense if the earmarking lasts for more than one issuance of the stats file.
Cheers Terry
Thanks for this. Yes, we have considered extending the stats file, but we were wondering if that level of detail is needed to track the last stages of IPv4. Unless people need it for other reasons as well, which we're interested to hear.
Would you mind adding the why, the benefits/risks and the reporting frequency, so others can share their views as well? Thanks!
Cheers, Sanjaya
On 1/12/10 Wed, Dec 1, 20:08, Sanjaya wrote:
Hi all,
At this stage, the total amount of reserved and reclaimed address space in APNIC accounts for 0.21 /8s and 0.14 /8s, respectively. These are part of a bigger unallocated pool available for distribution which is 3.67 /8 as of today.
While we have the ability to track our IPv4 stock level internally, we are still working on finalizing a public reporting format that meets the community needs. We'd like to hear more from you about how we can best do this, so please keep sending ideas to this list. We are monitoring this thread closely. Thanks.
I'm pleased to see these figures and I think that this level of detail is sufficient. A graph showing these three quantities would give us a view over time that would allow trends to be followed and any large discrepancies to be noted.
Questions could then be raised at APNIC meetings or on the appropriate mailing list.
I have no reason to believe that the APNIC staff are doing anything other than a responsible job here and therefore I don't believe we need to micromanage their every move by asking for detailed accounts of their actions.
Hi Andy,
I was also pleased to see these figures.
But the request for the detail is not for micromanagement of the APNIC staff. Far from it.
It is about transparency of registry data. The data partly exists already, but in my mind is incomplete.
This closes the loop and provides any researchers (like me) with a valuable set of authoritative information regarding the RIR/NIR pools. These pools are currently a black box.
Cheers Terry
I'm pleased to see these figures and I think that this level of detail is sufficient. A graph showing these three quantities would give us a view over time that would allow trends to be followed and any large discrepancies to be noted.
Questions could then be raised at APNIC meetings or on the appropriate mailing list.
I have no reason to believe that the APNIC staff are doing anything other than a responsible job here and therefore I don't believe we need to micromanage their every move by asking for detailed accounts of their actions.
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 3/12/10 Fri, Dec 3, 13:13, Terry Manderson wrote:
Hi Andy,
I was also pleased to see these figures.
But the request for the detail is not for micromanagement of the APNIC staff. Far from it.
It is about transparency of registry data. The data partly exists already, but in my mind is incomplete.
This closes the loop and provides any researchers (like me) with a valuable set of authoritative information regarding the RIR/NIR pools. These pools are currently a black box.
Terry,
Thanks for the clarification. If there are people like yourself who can make use of more detailed information and it can be made available in a straightforward manner then I see no reason to withhold it either.
andy
On 12/2/10 8:07 PM, "Andy Linton" asjl@lpnz.org wrote:
On 3/12/10 Fri, Dec 3, 13:13, Terry Manderson wrote:
Hi Andy,
I was also pleased to see these figures.
But the request for the detail is not for micromanagement of the APNIC staff. Far from it.
It is about transparency of registry data. The data partly exists already, but in my mind is incomplete.
This closes the loop and provides any researchers (like me) with a valuable set of authoritative information regarding the RIR/NIR pools. These pools are currently a black box.
Terry,
Thanks for the clarification. If there are people like yourself who can make use of more detailed information and it can be made available in a straightforward manner then I see no reason to withhold it either.
+1, and I'd like to hear about "various registries" as asked. Is it in the inventory now? If not, when?
Best,
-M<
Hi Marty,
On Dec 2, 2010, at 5:15 PM, Hannigan, Martin wrote:
[…]
+1, and I'd like to hear about "various registries" as asked. Is it in the inventory now? If not, when?
While I can't answer your question, you and other readers are presumably interested in the distribution. The NRO has provided an update and as with all important correspondence we have published it.
http://www.icann.org/en/correspondence/pawlik-to-vegoda-gerich-23nov10-en.pd...
Regards,
Leo
Thanks Leo for your info on various registry.
To all, the various registry information will be included in the calculation.
I'm noting divergence in the desired level of detail.
The detailed report is needed for transparency and research purposes (2 people)
Of those who don't want detailed report (4 people), 3 are concerned with APNIC spending its limited resource producing the report. One saw the risk of misuse.
I propose to produce a summarised daily public report first (with graph). We will look for a minimum effort and secure way to fulfill the research needs, but this comes later. Let me know how you feel about this approach. Thanks.
Cheers, ________________________________________________________________________ Sanjaya email: sanjaya@apnic.net Services Director, APNIC sip: sanjaya@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________ * Sent by email to save paper. Print only if necessary.
On 3/12/2010 11:15 AM, Hannigan, Martin wrote:
On 12/2/10 8:07 PM, "Andy Linton"asjl@lpnz.org wrote:
On 3/12/10 Fri, Dec 3, 13:13, Terry Manderson wrote:
Hi Andy,
I was also pleased to see these figures.
But the request for the detail is not for micromanagement of the APNIC staff. Far from it.
It is about transparency of registry data. The data partly exists already, but in my mind is incomplete.
This closes the loop and provides any researchers (like me) with a valuable set of authoritative information regarding the RIR/NIR pools. These pools are currently a black box.
Terry,
Thanks for the clarification. If there are people like yourself who can make use of more detailed information and it can be made available in a straightforward manner then I see no reason to withhold it either.
+1, and I'd like to hear about "various registries" as asked. Is it in the inventory now? If not, when?
Best,
-M<
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 Sanjaya,
Speaking strictly for myself.
I am confused, not by you including the various registry nor your observation of divergence in the opinions of 6 people. My confusion comes from the idea that a _new_ summary report with a graph is _easier_ and thus cheaper than extending and therefore completing the current stats already in place.
Now I am certainly not an uber-expert in databases, but to calculate a summary to produce a graph wouldn't the intermediate step be to get the records from the APNIC registry database by a SELECT in the first place? Wouldn't that be cheaper and easier to do _just_ that? i.e Just dump the data out in the already used format and let those who are interested in producing pretty graphs do so?
I really didn't expect this to be such a hard request for a registry. And I certainly didn't expect the noise this has generated. I understand that my desires may not be shared - but I consider this to be a basic (very basic) requirement of a registry. Maybe I'm wrong.
I also realise that APNIC members are very concerned about the costs of APNIC and the relative spending priorities. So since this does seem to be a request from me primarily I am more than willing to _donate_ my time to help the registry do this to reduce engineering costs and effort.
And to the others on the list, my apologies for the extended "noise."
Cheers Terry
On Fri, Dec 3, 2010 at 7:20 PM, Sanjaya sanjaya@apnic.net wrote:
Thanks Leo for your info on various registry.
To all, the various registry information will be included in the calculation.
I'm noting divergence in the desired level of detail.
The detailed report is needed for transparency and research purposes (2 people)
Of those who don't want detailed report (4 people), 3 are concerned with APNIC spending its limited resource producing the report. One saw the risk of misuse.
I propose to produce a summarised daily public report first (with graph). We will look for a minimum effort and secure way to fulfill the research needs, but this comes later. Let me know how you feel about this approach. Thanks.
On 3/12/2010, at 4:49 AM, Andy Linton asjl@lpnz.org wrote:
On 1/12/10 Wed, Dec 1, 20:08, Sanjaya wrote:
Hi all,
At this stage, the total amount of reserved and reclaimed address space in APNIC accounts for 0.21 /8s and 0.14 /8s, respectively. These are part of a bigger unallocated pool available for distribution which is 3.67 /8 as of today.
While we have the ability to track our IPv4 stock level internally, we are still working on finalizing a public reporting format that meets the community needs. We'd like to hear more from you about how we can best do this, so please keep sending ideas to this list. We are monitoring this thread closely. Thanks.
I'm pleased to see these figures and I think that this level of detail is sufficient. A graph showing these three quantities would give us a view over time that would allow trends to be followed and any large discrepancies to be noted.
Questions could then be raised at APNIC meetings or on the appropriate mailing list.
I have no reason to believe that the APNIC staff are doing anything other than a responsible job here and therefore I don't believe we need to micromanage their every move by asking for detailed accounts of their actions.
I agree with Andy. The stats don't need to be much more granular than the above, and if they were easily available in a chart (and maybe csv for those that want raw numbers) that would be excellent.
I don't want to see APNIC spending excessive amounts of time on this sort of request since it's very likely to be irrelevant before too much time has elapsed.
aj
Speaking for myself,
I have concerns about this policy.
Should any address space be handed to APNIC, in any fashion, I do not wish for APNIC to be the hoarding point for addresses. The final /8 policy allows one /22 (or what ever the size might be at the time) allocation to a full APNIC member. This results in the following breakdown:
o- A /16 reserved for future use (64 /22s) or until the rest of the /8 is allocated. o- 16320 /22s, one for each full APNIC member.
And since the current APNIC membership is at about 2460 I can't see the value in adding to that pool, as if it were enacted today, 13860 /22s would remain. What is the use case for augmenting that pool with the returned address blocks?
I would think APNIC should be doing its best to get any returned address space out to those who could use it (yes even in the face of the ipv6 push), meaning that a member will get an automatic /22, and if they need more over and above that - then I would consider the returned space as the ideal top-up reserve. (If not returned to IANA for distribution into other geographic regions where need might be great)
Do I necessarily think the current policies are viable for a reserve pool like this, no. I'm not sure what would be 'right' in policy terms just now, but certainly more liberal than what currently is in play.
The interesting thing about this proposal is that it would create an artificial restriction on v4 address space in the AP region. This might facilitate more v6 deployment, or might just make the IPv4 'exchanges' between organisations more expensive. Irrespective of this observation, I don't believe APNIC should enact any policy that restricts v4 allocations based on need either in region, or out.
I cannot support this proposal as written.
Cheers Terry
On 23/11/2010, at 11:14 AM, Terence Zhang YH wrote:
Dear SIG members,
The proposal, 'Distribution of IPv4 addresses once the final /8 period starts', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 29 in Kuala Lumpur, 21-25 February 2011.
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 and other policy proposals is available from:
http://www.apnic.net/policy/proposalsGaurab, Ching-Heng, and Terence
prop-088-v001: Distribution of IPv4 addresses once the final /8 period starts ________________________________________________________________________
Author: Randy Bush randy@psg.com
Philip Smith <pfs@cisco.com>Version: 1
Date: 22 November 2010
- Introduction
This is a proposal to handle any IPv4 address space received by APNIC after the final /8 policy is implemented as being part of the final /8 pool and to redistribute these resources according to the final /8 policies.
- Summary of current problem
After APNIC has activated the "final /8" allocation policies[1], there is the possibility that APNIC will receive further IPv4 addresses. These IPv4 addresses will come either directly from Asia Pacific networks that no longer need them, or, if the global policy proposal for redistributing resources from the IANA succeeds, from the IANA.
The intent of the authors of the original final /8 policy proposal was to have all other IPv4 allocation and assignment policies replaced by the delegation policy described in the final /8 policy. However, the current language of the final /8 policy does not explicitly repeal the other IPv4 allocation and assignment policies. The authors are therefore aware that there may be some confusion as to how such returned addresses should be distributed by APNIC. This proposal seeks to clarify the situation.
- Situation in other RIRs
There is no similar policy or proposal in other regions.
- Details of the proposal
It is proposed that:
4.1 When APNIC has distributed all other available IPv4 resources, and has to start distributing from the final /8, any IPv4 resources received after that point will be placed into the final /8 pool.
- This placement into the final /8 pool will occur even if the result is a pool larger than one /8. - Subject to any future global policy for the redistribution of addresses received by the IANA from the RIRs (for example, prop-069), this placement applies to any IPv4 addresses APNIC receives from: - the IANA; and/or - holders of addresses in the APNIC Whois Database4.2 These resources received in 4.1 are to be distributed according to the same policies as apply to the final /8 [1].
- Advantages and disadvantages of the proposal
5.1 Advantages
- It reduces confusion possible if IPv4 resources are received outside the final /8 but during the period when the final /8 policy is active by explicitly stating how these IPv4 resources are to be handled.5.2 Disadvantages
- No disadvantages are foreseen.
- Effect on APNIC members
APNIC members can only request and receive a single distribution from the final /8. This would also apply to any other IPv4 addresses placed in the final /8 pool by this policy.
- Effect on NIRs
This will affect NIR members in the same way as APNIC members.
- References
[1] Section 9.10 "Distribution of the final /8 worth of space in the unallocated APNIC IPv4 address pool" of "Policies for IPv4 address space management in the Asia Pacific region" http://www.apnic.net/policy/add-manage-policy#9.10 _______________________________________________
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
Activity Summary
- 4674 days inactive
- 4674 days old
- sig-policy@lists.apnic.net
- 14 participants
- 32 comments