APNIC 57 POLICY PROPOSALS
February 22, 2024
APNIC 57 (APRICOT 2024) is being held in Bangkok, Thailand, this year from February 21st to March 1st. This year there are four new policy proposals up for community discussion.
prop-154 (Resizing of IPv4 assignment for the IXPs) – Current policy allows new IXPs to receive /23 (IPv4) and /48 (IPv6) max. Usually APNIC assigns one /24, but after analyzing PeeringDB, they found that new IXPs are underutilizing and large IXPs cannot grow due to lack of IPv4 resources. The objective of this proposal is to change the standard size of IPv4 assignments for IXPs from /23 to /26, but if an IXP were to return the space they were initially assigned, they would be able to receive a replacement of up to a /22. It proposed that new IXPs will get /26 IPv4 assignment by default. Larger allocations (ranging up to /25 or /23) can be requested depending on the number of peers on the IXP fabric. Established IXPs also have the option to request larger allocations or establish new Points of Presence (POPs). Resources allocated must be exclusively utilized for IXP peering and are prohibited from being transferred. IXPs can decide on the global routability of the delegation. This policy proposal suggests that APNIC set aside a reservation of up to /20 for IXPs.
There is a diversity of opinions on the proposal, with some supporting it for its potential to facilitate IXP expansion, and others opposing it because they think once all IPv4 resources are allocated, IXPs can move to IPv6 entirely. Some also oppose this proposal because they don’t think the expansion of IXPs depends on the allocation size, but on market dynamic (factors such as availability of ISPs, CDNs, and Telcos), so they argue that reducing the default size of IP assignments can in fact hinder operations, not the other way around.
prop-156 (Assignment of Temporary IP Resources) – Currently APNIC doesn’t have a policy that allows temporary IP resource assignments, except for experimental space in Section 5.7 of APNIC-127. Entities that need resources for temporary events must use existing delegations under different policies, which doesn’t align with the original justification. The proposal recommends setting aside a /21 IPv4 prefix from the non-103/8 pool, along with a /29 IPv6 prefix and 8 Autonomous System Numbers. Long Term assignment is not practical, so these resources will be designated for delegation to events like conferences and other situations where APNIC deems it appropriate. The proposal suggests reserving 1x /21 from non-103/8 pool, 1x /29 for IPv6, and 8x ASNs. The assignment period allowed is 6 months.
Overall, the sentiments of the community seem to lean toward supporting the proposal, with a recognition of the potential benefits for non-profit events and acknowledgment of some concerns such as: considering for commercial events that are not non-profit, and searching for alternatives that provide similar services. The community members commented on alternatives such as CGNAT and IPv6, but the author justified the proposal by pointing out the constraints of current policies, highlighting the importance of using resources for events without profit intentions, and acknowledging the difficulties that may arise with alternative solutions such as CGNAT.
prop-157 (Temporary IPv4 Transfers) – The objective of this proposal is to modify the existing temporary transfer system (already accepted by the community), to function for leasing in the APNIC region. This approach ensures policy compliance, security, and controlled return of addresses when the leasing period concludes. This will help cater smaller entities with modest investments before they leap into the goal of IPv6 deployment. The policy proposes that APNIC maintain a public record of all transfers of number resources (Ipv4, Ipv6, ASNs), including market transfers, M&A, and legacy transfers. For temporary IPv4 transfers, the log will include the initial and final dates. If transfer period is extended, the log must be updated (requires 30 days’ notice). Once temporary transfer period ends, APNIC will restore the original registration information in the Whois Database. Conditions for permanent and temporary IPv4 transfers: Smallest and largest transferrable IPv4 size is /24 and /22, respectively, per recipient. The address must be either assigned or allocated to current APNIC account holder. Recipient must also be compliant with current APNIC policies, such as providing plan for resource utilization within 24 months. Existing resource holder must show past usage data, evidence of compliance, and a plan that align with the initial expected transfer period. Failure to comply with the supplementary conditions will result in immediate revocation of the resources; the conditions include network abuse, the necessity of an ASN, operation IPv4, accurate IRR and geolocation updates, and adherence to MANRS best practice. If passed, the EC can establish specific rates for these transfers and extensions.
There were mixed opinions on this proposal as well; while most want to support the idea of temporary transfers, before accepting this proposal, they would like to refine the proposal by addressing issues such as the proposal’s impact on current policies, applicable transfer fees, addition a minimum transfer period instead of unlimited extension, and the cost that will accrue with the need for tracking the temporary transfer separately.
prop-158 (IPv6 auto-allocation for each IPv4 request) – Most new members seeking IPv4 don’t request IPv6 even though they are eligible and there is no additional cost. IPv4 allocation rates are higher than IPv6; the author believe that this might slow the deployment of IPv6. The objective of this proposal is to automatically allocate IPv6 addresses to each IPv4 address requests to speed up IPv6 adoption and deployment. If passed, this policy will be added to Section “6.1. Minimum and maximum IPv4 delegation” of the APNIC Policy document. For all initial IPv4 requests, IPv6 will be automatically delegated; they should be put into deployment within two years for the delegation date. For any future IPv4 requests, requestors should be able to demonstrate the deployment status of the automatically delegated IPv6 space. This proposal also covers a range of perspectives; the community touches upon technical and legal topics.
The community discussion mostly revolves around NIRs’ role; some argue that NIRs should not have their own set of policies while others argue otherwise so long as they don’t have conflict with the RIR’s policies. They also discussed the need for clarity in the proposal, and the need to clarify the appropriate IPv6 size for various allocations. Although some members agree to the idea of automatic IPv6 allocation, participants bring up issues and requested clarification on some proposal solution before they can come to a consensus. The community discussed the administrative burden and risks that comes with automatic allocation of IPv6 addresses. They also debated about whether the proposal is relevant to speed up IPv6 adoption and they are skeptical that entities would adopt IPv6 even if the IPv6 delegation was enforced upon them.