Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[AfriNIC-rpd] Policy Proposal (Global): IANA Policy for Allocation of ASN Blocks to RIRs

Philip Smith pfs at cisco.com
Fri Aug 28 13:38:26 UTC 2009


Hi Frank,

Vendors who ship software supporting configuration of 4-byte ASNs in BGP
are listed at http://as4.cluepon.net - I think you'll find that it is
quite extensive.

The cynic might now say that the ISPs should be blamed for not upgrading
to software that allows them to fully support customers with 4-byte ASNs
(i.e. be able to implement routing policy). The realist would then point
out that this quite often involves hardware upgrades too. ;-)

Whatever, I agree with you that this proposal is quite essential to
ensure that AfriNIC can still receive 2-byte ASNs from the IANA after
the end of this year.

philip
--



Frank Habicht said the following on 28/8/09 23:12 :
> I support the policy proposal.
> 
> That is for very practical reasons. Adoption of 32-bit ASNs has just not
>  taken place to a significant extend.
> 
> In addition I wonder if some "blame" can be put on vendors of BGP
> speakers. I wonder if RIRs or NRO can somehow "motivate" vendors to
> actively support and encourage deployment of products (the right
> software should mostly do) to enable inter-operation with 32-bit ASNs,
> including direct peering with them. Like giving the upgraded software
> away for free (with easy process).
> 
> Thanks,
> Frank
> 
> 
> 
> vincent at kenic.or.ke wrote:
>> The AfriNIC PDP-MG received the following policy proposal from Andrew de
>> la Haye from the RIPE NCC region. The policy proposal is a prospective
>> global policy as it has already been submitted in all the other RIR's. In
>> accordance with the AfriNIC Policy Development Process, the proposal is
>> being posted to the AfriNIC Resource Policy Discuss (RPD) Mailing List.
>> The proposal will also be placed on the AfriNIC website as a policy
>> proposal under discussion.
>>
>> In line with the AfriNIC PDP, the AfriNIC community is now invited to
>> review and discuss this policy.
>>
>> The AfriNIC Policy Development Process can be found at:
>> http://www.afrinic.net/docs/policies/afpol-pdp200707.htm
>>
>> AfriNIC Mailing Lists subscription information can be found at:
>> http://www.afrinic.net/mailinglist.htm
>>
>> Regards,
>>
>> Vincent Ngundi
>> Chair, PDP-MG
>>
>> ############ IANA Policy for Allocation of ASN Blocks to RIRs ###########
>>
>> Name:               Andrew de la Haye (andrew at ripe.net), Stacy Hughes
>> (ipgoddess.arin at gmail.com)
>> Organisation:
>> Policy Affected:    IANA Policy for Allocation of ASN Blocks to RIRs
>> (afpol-asn200708)
>> Date:               27 May 2009
>> Proposal:           Internet Assigned Numbers Authority (IANA) Policy for
>> Allocation of ASN Blocks (ASNs) to Regional Internet Registries (Global
>> Policy proposal)
>>
>> Summary of proposal:
>>
>> According to the current global policy (afpol-asn200708), 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.
>>
>>
>> Policy text
>>
>> Current Policy Text (in current afpol-asn200708):
>>
>> 1. Allocation Principles
>>
>> 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 2009,
>> allocations of 2-byte only and 4-byte only ASN blocks will be made
>> separately and independent of each other. This means until 31 December
>> 2009, RIRs can receive two separate ASN blocks, one for 2-byte only ASNs
>> and one for 4-byte only ASNs from the IANA under this policy. After this
>> date, IANA and the RIRs will cease to make any distinction between 2-byte
>> only and 4-byte only ASNs, and will operate ASN allocations from an
>> undifferentiated 4-byte ASN allocation pool.
>>
>>>>
>> http://www.afrinic.net/docs/policies/afpol-asn200708.htm
>>
>>
>> New Policy Text:
>>
>> 1. Allocation Principles
>>
>> 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
>>
>> Rationale:
>> a. Arguments supporting the proposal
>>
>> 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.
>>
>> b. Arguments opposing the proposal
>>
>> 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.
>>
>> #######################
>>
>>
>>
>> _______________________________________________
>> rpd mailing list
>> rpd at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> 
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> 




More information about the RPD mailing list