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, 'Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 28 in Beijing, China, 25-28 August 2009. The proposal's history can be found at:
http://www.apnic.net/policy/prop-074
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?
Randy, Jian and Ching-Heng
________________________________________________________________________
prop-074-v001: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries ________________________________________________________________________
Authors: Andrew de la Haye, RIPE NCC andrew@ripe.net
Stacy Hughes ipgoddess.arin@gmail.com
Version: 1
Date: 13 July 2009
1. Introduction ----------------
This is a global policy proposal.
According to the current Global Policy for Allocation of ASN Blocks to Regional Internet Registries, IANA will cease to make any distinction between 16-bit and 32-bit only ASN blocks by 31 December 2009, when making allocations to RIRs. This proposal is to extend this date by one year, to 31 December 2010.
2. Summary of current problem ------------------------------
Due to operational issues external to the IANA/RIR policy process, 32-bit only ASNs are not being issued by the RIRs at the anticipated rate. As it stands, RIRs will likely not be able to justify a new block of ASNs from the IANA after 31 December 2009 due to a glut of free 32 bit only ASNs in the RIR’s pool. This leaves available, essential 16-bit ASNs stranded in the IANA free pool. This proposal seeks to remedy the potential problem by extending the deadline for differentiation by one year.
With this proposal the policy will be aligned with the actual reality in regards to 32-bit ASN deployment and usage.
The subject was raised during RIPE 58 and a presentation was made:
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-u...
The feedback in this session suggested that a global policy proposal should be developed and should be discussed.
3. Situation in other RIRs ----------------------------
This is a global policy proposal and will be submitted to all RIRs.
- ARIN
Submitted. Currently with the ARIN Address Council for development and evaluation
- RIPE
2009-07: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries
http://www.ripe.net/ripe/policies/proposals/2009-07.html
- AfriNIC, LACNIC
To be submitted
4. Details of the proposal ----------------------------
This proposal suggests changing the "Allocation Principles" section of the Global Policy for Allocation of ASN Blocks to Regional Internet Registries [i] to:
IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010, allocations of 16-bit and 32-bit only ASN blocks will be made separately and independent of each other [1].
This means until 31 December 2010, RIRs can receive two separate ASN blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 16-bit and 32-bit only ASNs, and will operate ASN allocations from an undifferentiated 32-bit ASN allocation pool.
[1] 16-bit ASNs are the AS Numbers in the range: 0 - 65535 32-bit only ASNs are the AS Numbers in the range: 65536 - 4294967295 32-bit ASNs are the AS Numbers in the range: 0 - 4294967295
5. Advantages and disadvantages of the proposal -------------------------------------------------
Advantages:
See the section above, "2. Summary of current problem".
Disadvantages:
Some may think that extending the previously set timeline can be perceived as some discouragement for the deployment of 32-bit ASNs. One counter argument to this is that RIRs and Internet community have some other mechanisms and activities to raise awareness for 32-bit ASN pool (via public presentations and trainings). These activities will continue while 16-bit ASN blocks are still allocated to RIRs by the IANA as they are available and they are needed.
6. Effect on APNIC members ----------------------------
Authors cannot think of any effect other than that if the proposal is accepted, APNIC members will be able to keep receiving 16 bit ASNs if they need to because APNIC will be able to receive 16 bit ASN blocks from IANA.
7. Effect on NIRs -------------------
Same as above.
8. References ---------------
[i] Global Policy for Allocation of ASN Blocks to Regional Internet Registries www.icann.org/en/general/global-policy-asn-blocks-31jul08-en.htm _______________________________________________ Sig-policy-chair mailing list Sig-policy-chair@apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy-chair
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Will it be possible for the APNIC secretariat to compile the data for the APNIC region, as is done in the slides by Daniel @ RIPE NCC, referenced in the proposal.
- -gaurab
Ching-Heng wrote:
With this proposal the policy will be aligned with the actual reality in regards to 32-bit ASN deployment and usage.
The subject was raised during RIPE 58 and a presentation was made:
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-u...
Hi all,
My apologies for this delayed response. Yes, we could provide data set similar to pages 2 to 4 in the referenced RIPE-NCC presentation. We should be able to share it by next week.
Cheers,
One of the stumbling blocks for deployment of 32-bit ASNs is getting versions of code on routers up to a level that can support this. This table may help:
Dear Gaurab, Ching-Heng and all,
Below is APNIC 1Q data in the same format as the referenced RIPE presentation (page 2 to 4).
2009 Q1 Statistics (1 Jan - 31 Mar 2009)
• Out of the 97 assigned ASNs we know that:
- 85 were 16-bit (requested from start, reasons were supplied during first request) - 6 were 16-bit (swapped from 32-bit to 16-bit) - 6 were 32-bit
Why 32-bit was exchanged for 16-bit:
• 1 (17%) - their network devices (or part of them) do not support 32-bit ASNs, hardware is outdated, no update is available
• 0 (0%) - the OS version on the router which will act as border router doesn't support 32-bit ASN yet
• 4 (66%) - the upstream provider does not support 32-bit ASNs, device is not yet available
• 1 (17%) - one (or more) of the peering partners do not support 32-bit ASNs
• 0 (0%) - the main transit provider does not support 32-bit ASNs
• 0 (0%) - the Internet Exchange does not support 32-bit ASNs
Regards,
Sanjaya,
On Jul 24, 2009, at 12:03 AM, Sanjaya wrote:
• Out of the 97 assigned ASNs we know that:
- 85 were 16-bit (requested from start, reasons were supplied during
first request)
- 6 were 16-bit (swapped from 32-bit to 16-bit)
- 6 were 32-bit
Sorry, this is a bit confusing to me.
Is this indicating that of the 6 32-bit ASNs, all 6 were swapped with 16-bit ASNs or is it that there were 12 32-bit ASNs, of which 6 were swapped to 16-bit?
Out of curiosity, has there been any investigation as to what AS numbers might be reasonably reclaimed?
Thanks, -drc
David Conrad wrote:
Sanjaya,
On Jul 24, 2009, at 12:03 AM, Sanjaya wrote:
• Out of the 97 assigned ASNs we know that:
- 85 were 16-bit (requested from start, reasons were supplied during
first request)
- 6 were 16-bit (swapped from 32-bit to 16-bit)
- 6 were 32-bit
Sorry, this is a bit confusing to me.
Is this indicating that of the 6 32-bit ASNs, all 6 were swapped with 16-bit ASNs or is it that there were 12 32-bit ASNs, of which 6 were swapped to 16-bit?
Hi David,
It's the latter. There were 12 32-bit ASNs, of which 6 were swapped to 16-bit. Sorry for the confusion.
Out of curiosity, has there been any investigation as to what AS numbers might be reasonably reclaimed?
prop-075 is one possibility :)
http://www.apnic.net/policy/proposals/prop-075
Cheers, Sanjaya ___________________________________________________ Join us for APNIC 28 in Beijing : 25-28 August 2009
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thanks Sanjaya,
The numbers are rather low but still useful.
I have no problems with the proposal. Though, I believe that pushing the date further away only decreases the pressure on the vendors and others to adopt.
thanks -gaurab
Dear Gaurab and all,
I agree with Gaurab's comment. Maybe, we need to find alternative way to keep the pressure.
Rgs, Masato Yamanishi
-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy-bounces@lists.apnic.net] On Behalf Of Gaurab Raj Upadhaya Sent: Friday, August 07, 2009 1:50 AM To: Sanjaya Cc: 'sig-policy' Subject: Re: [sig-policy] prop-074: IANA policy for allocation of ASN blocks to RIRs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thanks Sanjaya,
The numbers are rather low but still useful.
I have no problems with the proposal. Though, I believe that pushing the date further away only decreases the pressure on the vendors and others to adopt.
thanks -gaurab
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkp7CbcACgkQSo7fU26F3X2MYgCfZ+9wyXnhTtQ6yTJi41esU0ig 82MAoOdKC09T29HTdopM0kY5ZOMz3wkD =9aoo -----END PGP SIGNATURE-----
sig-policy: APNIC SIG on resource managementpolicy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
I support this proposal, at it seems to be required to ensure all 16-bit AS numbers currently held at the IANA level are used up.
Regards,
David Woodgate
At 04:38 PM 13/07/2009, Ching-Heng wrote:
Dear SIG members,
The proposal, 'Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries', has been sent to the Policy SIG for review. It will be presented at the Policy SIG at APNIC 28 in Beijing, China, 25-28 August 2009. The proposal's history can be found at:
http://www.apnic.net/policy/prop-074We 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?Randy, Jian and Ching-Heng
prop-074-v001: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries ________________________________________________________________________
Authors: Andrew de la Haye, RIPE NCC andrew@ripe.net
Stacy Hughes <ipgoddess.arin@gmail.com>Version: 1
Date: 13 July 2009
- Introduction
This is a global policy proposal.
According to the current Global Policy for Allocation of ASN Blocks to Regional Internet Registries, IANA will cease to make any distinction between 16-bit and 32-bit only ASN blocks by 31 December 2009, when making allocations to RIRs. This proposal is to extend this date by one year, to 31 December 2010.
- Summary of current problem
Due to operational issues external to the IANA/RIR policy process, 32-bit only ASNs are not being issued by the RIRs at the anticipated rate. As it stands, RIRs will likely not be able to justify a new block of ASNs from the IANA after 31 December 2009 due to a glut of free 32 bit only ASNs in the RIR's pool. This leaves available, essential 16-bit ASNs stranded in the IANA free pool. This proposal seeks to remedy the potential problem by extending the deadline for differentiation by one year.
With this proposal the policy will be aligned with the actual reality in regards to 32-bit ASN deployment and usage.
The subject was raised during RIPE 58 and a presentation was made:
http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-u...
The feedback in this session suggested that a global policy proposal should be developed and should be discussed.
- Situation in other RIRs
This is a global policy proposal and will be submitted to all RIRs.
ARIN
Submitted. Currently with the ARIN Address Council for development and evaluation
RIPE
2009-07: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks (ASNs) to Regional Internet Registries
http://www.ripe.net/ripe/policies/proposals/2009-07.htmlAfriNIC, LACNIC
To be submitted
- Details of the proposal
This proposal suggests changing the "Allocation Principles" section of the Global Policy for Allocation of ASN Blocks to Regional Internet Registries [i] to:
IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010, allocations of 16-bit and 32-bit only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2010, RIRs can receive two separate ASN blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 16-bit and 32-bit only ASNs, and will operate ASN allocations from an undifferentiated 32-bit ASN allocation pool. [1] 16-bit ASNs are the AS Numbers in the range: 0 - 65535 32-bit only ASNs are the AS Numbers in the range: 65536 - 4294967295 32-bit ASNs are the AS Numbers in the range: 0 - 4294967295
- Advantages and disadvantages of the proposal
Advantages:
See the section above, "2. Summary of current problem".Disadvantages:
Some may think that extending the previously set timeline can be perceived as some discouragement for the deployment of 32-bit ASNs. One counter argument to this is that RIRs and Internet community have some other mechanisms and activities to raise awareness for 32-bit ASN pool (via public presentations and trainings). These activities will continue while 16-bit ASN blocks are still allocated to RIRs by the IANA as they are available and they are needed.
- Effect on APNIC members
Authors cannot think of any effect other than that if the proposal is accepted, APNIC members will be able to keep receiving 16 bit ASNs if they need to because APNIC will be able to receive 16 bit ASN blocks from IANA.
- Effect on NIRs
Same as above.
- References
[i] Global Policy for Allocation of ASN Blocks to Regional Internet Registries www.icann.org/en/general/global-policy-asn-blocks-31jul08-en.htm _______________________________________________ Sig-policy-chair mailing list Sig-policy-chair@apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy-chair
sig-policy: APNIC SIG on resource managementpolicy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Activity Summary
- 5210 days inactive
- 5210 days old
- sig-policy@lists.apnic.net
- 7 participants
- 9 comments