Hi
I don't understand very much your questions below and where you want to
get to, but basically to resume it, in the currency exhaustion scenario
there must be a distinction from those who have already some IP space
allocation and those who have nothing.
Those who have can have revenue from that and with time transfer more IP
space from the market as business grow. Those who have nothing doesn't
even have this chance. That's why giving that little space left to those
who already have something will basically serve to allow them save some
money in not having to the market and transfer them for those who would
become eligible for another /23.
It is still possible to see many companies believing they still need a
lot of IPv4 addresses for stuff that doesn't really require. With a
single IP address it is possible to host several different services or
in broadband scenarios to get connectivity to multiple users with good
IPv6 transition techniques or well designed CGNAT just to mention a few
examples.
I don't see a justification to accelerate the depletion of the current
pool with little benefit to the community in the region.
New entrants can benefit from this IP space left a lot more than the
existing one who have already something to work with.
Fernando
On 8/17/2026 5:14 PM, Jonathan Brewer wrote:
Hi Fernando,
Thank you for expressing some strong opinions regarding prop-168-v003.
For the benefit of the list, can you give us some background on how
you formed these opinions? In particular:
1. "For the main point about the proposal a /23, as it is now, is
enough for new entrants to begin with and exist in the internet."
2. "No more space should be given from these pools to account holders
who already have some space."
3. "Existing ones, with little IP space such as a /23 have already
some means and revenue to transfer in more IP space and continue
growing."
Were these opinions formed working for an operator in the APNIC
community? If so in what capacity, and for how long?
Regards,
Jon
On Tue, 18 Aug 2026, at 03:21, Fernando Frediani wrote:
Hello
I want to share below the reasons I do NOT support this proposal.
- First I want to say that I find it very positive and correct the
care the author took to exclude from from this account holders who
have transferred out any IPv4 as also the 5 years for not being able
to transfer out resources received by APNIC. This make proposal more
coherent and reduces speculation around resources numbers.
- I don't think the proposal for a /16 for facilitating IPv6
deployment should be treated under this same proposal. It is a
different topic and should be treated and discussed separately.
- For the main point about the proposal a /23, as it is now, is
enough for new entrants to begin with and exist in the internet.
- No more space should be given from these pools to account holders
who already have some space. Any space left from APNIC's pool should
be given to new entrants so they privilege more organizations to
exist on the internet rather than concentrate on the existing ones.
- Existing ones, with little IP space such as a /23 have already some
means and revenue to transfer in more IP space and continue growing.
They should not depend on APNIC for that. Allowing that only serves
for the propose of exhaust the little left for these new entrants. I
normally tend to think that for a new organization to exist on the
internet a /23 or /22 is little but Ok. It allows it to establish
itself in business and go from there with its own legs. As the status
quo for APNIC is /23 it doesn't sound good move to change it.
On discussions about such possible changes on RIRs I tend to think
that it seems that people still didn't understand we are under a
heavy IPv4 exhaustion and simply there aren't IPv4 available for the
pace Internet demand grows. Maybe some think that by adjusting the
policy to exhaust the pool much faster will resolve the issue for
some and all it may do is save some money for those who are able to
get this extra tiny chunk of IP space avoiding them to pay to
transfer from the market. This at the cost of new entrants which
makes it unfair in unbalanced in my view given the current scenario.
People need to learn how to work with less IPv4 on deployments, make
better usage of what they already have instead of keep hoping to
receive some extra space from their RIRs.
Best regards
Fernando
On 8/4/2026 9:01 PM, David Mitchell via SIG-policy wrote:
Hi All,
I support this proposal and believe it is clear.
Regards
David Mitchell
*From:*Bikram Shrestha <[email protected]> <mailto:[email protected]>
*Sent:* Saturday, 1 August 2026 4:21 am
*To:* [email protected] <mailto:[email protected]>
*Cc:* [email protected] <mailto:[email protected]>
*Subject:* [sig-policy] Updated: prop-168-v003: Increase to maximum
IPv4 delegations
You don't often get email from [email protected]
<mailto:[email protected]>. Learn why this is important
<https://aka.ms/LearnAboutSenderIdentification>
Dear SIG members,
A new version of the proposal "prop-168: Increase to maximum IPv4
delegations” has been sent to the Policy SIG for review.
Information about earlier versions is available from:
https://www.apnic.net/community/policy/proposals/prop-168/
<https://www.apnic.net/community/policy/proposals/prop-168/>
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.
prop-168-v003: Increase to maximum IPv4 delegations
-----------------------------------------------------------------------------------
Proposers:
Christopher Hawker ([email protected] <mailto:[email protected]>)
1. Problem statement
-------------------------
As of 29 July 2026, there were 3,013,120 IPv4 addresses (11,770 x
/24) in the available pool [1]. Since prop-127 was implemented back
on 04 April 2019
there were 549 new account holders in 2025 (as of 03/12/2025), 667
new account holders in 2024 [2], 904 in 2023 [3], 824 in 2022 [4],
783 in 2021 [5],
827 in 2020 [6] and 841 in 2019 [7] (noting that this also includes
Q1 2024 which was prior to implementation of prop-127). At the
current average of
727 new accounts per year, and if each account holder was to apply
for the maximum delegation of /23, the delegation rate would be
approximately 1454
x /24 per year, meaning the pool will be exhausted in 2035. This
means that resources will sit idle in the available pool for an
extended period (up
to 9 years), while current account holders are required to acquire
additional space through market transfers or lease address space to
meet operational
requirements.
[Note: Full-year new account holder statistics for 2025 were not
published in the APNIC 2025 Annual Report.]
2. Objective of policy change
----------------------------------
Current address policy only allows for the maximum delegation of up
to and including a /23 to new and existing account holders. This
policy change will
allow a sub-set of account holders with less than an aggregated /22
to receive an additional delegation of up to a maximum of a /22 IPv4
delegation.
3. Situation in other regions
--------------------------------
- The maximum size aggregate a member in the ARIN region may qualify
for at any one time a maximum is a /22 [8].
- "The sum of all allocations made to a single LIR by the RIPE NCC
is limited to a maximum of 256 IPv4 addresses (a single /24)." [9]
- Exhaustion Phase 2 (section 5.4.3.2) in AFRINIC's Consolidated
Policy Manual states that the "maximum will be /22 per
allocation/assignment" [10].
- LACNIC's Policy Manual lists under section 11.1.4 "Policies
Relating to the Exhaustion of IPv4 Address Space" that the maximum
size a new member may
receive is a /22, while under 11.1.2 it states that existing
members are ineligible for additional space under this policy [11].
4. Proposed policy solution
--------------------------------
Update "APNIC-127 APNIC Internet Number Resource Policies" with the
below:
- Delete paragraphs 2 and 3 from section 6.1 "Minimum and maximum
IPv4 delegations", and replace with the following:
Account holders who hold less than a /22 may apply for additional
space, to bring their combined holdings up to and including a /22.
Account holders who have transferred any IPv4 address space of any
size out of their account are ineligible for further delegations
from APNIC.
- Delete paragraph 4 from section 11.0 "IPv4 Transfers", and replace
with the following:
Addresses delegated from the available pool cannot be transferred
for a minimum of five years from the date of delegation. If an
account holder received
an initial delegation and applies for a subsequent delegation, all
delegations to the account holder cannot be transferred for a
minimum of 5 years from
the date of the most recent delegation.
- Update point 4 from paragraph 1 under section 11.1.1 "Conditions
on the space to be transferred" as below:
Addresses delegated from the available pool cannot be transferred
for a minimum of five years from the date the original delegation
was made. If the
source entity received a delegation from APNIC within the last 5
years, any resources delegated from the available pool (including
those delegated over
5 years ago) cannot be transferred for a minimum of 5 years from the
date the most recent delegation was made.
- Delete paragraph 3 from section 11.2.1 "Conditions on the space to
be transferred" and replace with the following:
Some RIRs, including APNIC, have restrictions against the transfer
of certain address blocks. APNIC policy does not allow the transfer
of address space
delegated from the available pool to be transferred for a minimum of
five years from the date of the most recent delegation to the
account holder.
- Delete paragraph 2 from section 14.0 "Mergers & Acquisitions" and
replace with the following:
Addresses delegated from the available pool cannot be transferred
for a minimum of five years from the date of the most recent
delegation from the
available pool.
- Add new section 5.1.5 "Reservation for IPv4 to IPv6 Transitioning":
APNIC will reserve a /12 IPv4 subnet from the available pool, for
the purpose of delegating a maximum /24 address block to each new
account holder, in
order to assist with IPv4 to IPv6 transitioning once the available
pool for delegation has been exhausted. IPv4 addresses delegated
from this pool are
ineligible for transfers, and must be returned to APNIC when no
longer required. Account holders who currently hold or have ever
held IPv4 address
space are ineligible for address space under this policy, except
where that space was returned to APNIC. Delegations from this pool
will be made once
all other address space available or reserved for general delegation
have been exhausted.
If an account holder receives an IPv4 delegation under this policy
and is found to not be using the address space for IPv4-to-IPv6
transitioning, APNIC
may recover the IPv4 resources from the account holder.
- Delete sentence 2, paragraph 2, section 5.7.2 "Allocations for
experimental purposes" which currently reads:
This address space will be unreserved and put back in the general
pool after five years for delegation to account holders as per IPv4
policy in Section
6.0 below.
5. Advantages / Disadvantages
------------------------------------
Advantages:
- This will help to make additional resources available to
organisations who need it, that would otherwise need to acquire
space through market
transfers or lease address space.
Disadvantages:
- This policy will accelerate the exhaustion of IPv4 address space,
however, given the slow rate of new accounts
the benefits of additional space becoming available to account
holders outweigh the disadvantages of accelerated exhaustion.
- This may create a sudden rush of new applications for additional
resources, leading to extended waiting times for the assessment of
applications.
6. Impact on resource holders
-----------------------------------
No known impacts to resource holders.
7. References
----------------
[1] APNIC Delegation Statistics as of 29 July 2026:
https://ftp.apnic.net/stats/apnic/2026/delegated-apnic-extended-20260729.gz
<https://ftp.apnic.net/stats/apnic/2026/delegated-apnic-extended-20260729.gz>
[2] Page 22, APNIC 2024 Activity Report:
https://www.apnic.net/wp-content/uploads/2025/02/APNIC-AR-2024.pdf
<https://www.apnic.net/wp-content/uploads/2025/02/APNIC-AR-2024.pdf>
[3] Page 19, APNIC 2023 Activity Report:
https://www.apnic.net/wp-content/uploads/2024/02/APNIC_AR_2023.pdf
<https://www.apnic.net/wp-content/uploads/2024/02/APNIC_AR_2023.pdf>
[4] Page 17, APNIC 2022 Activity Report:
https://www.apnic.net/wp-content/uploads/2023/05/APNIC_AR_2022_FINAL.pdf
<https://www.apnic.net/wp-content/uploads/2023/05/APNIC_AR_2022_FINAL.pdf>
[5] Page 17, APNIC 2021 Activity Report:
https://www.apnic.net/wp-content/uploads/2022/03/APNIC_AR_2021.pdf
<https://www.apnic.net/wp-content/uploads/2022/03/APNIC_AR_2021.pdf>
[6] Page 18, APNIC 2020 Activity Report:
https://www.apnic.net/wp-content/uploads/2021/03/APNIC-2020-Annual-Report.pdf
<https://www.apnic.net/wp-content/uploads/2021/03/APNIC-2020-Annual-Report.pdf>
[7] Page 30, APNIC 2019 Activity Report:
https://www.apnic.net/wp-content/uploads/2020/02/APNIC-AR-2019-FINAL.pdf
<https://www.apnic.net/wp-content/uploads/2020/02/APNIC-AR-2019-FINAL.pdf>
[8] ARIN Waitlist, Number Resource Policy Manual, ARIN:
https://www.arin.net/participate/policy/nrpm/#4-1-8-arin-waitlist
<https://www.arin.net/participate/policy/nrpm/#4-1-8-arin-waitlist>
[9] Allocations made by the RIPE NCC to LIRs, IPv4 Address
Allocation and Assignment Policies for the RIPE NCC Service Region,
RIPE NCC:
https://www.ripe.net/publications/docs/ripe-826/#51-allocations-made-by-the-ripe-ncc-to-lirs
<https://www.ripe.net/publications/docs/ripe-826/#51-allocations-made-by-the-ripe-ncc-to-lirs>
[10] Soft Landing, Consolidated Policy Manual, AFRINIC:
https://afrinic.net/policy/manual#Soft-Landing
<https://afrinic.net/policy/manual#Soft-Landing>
[11] Policies relating to the Exhaustion of IPv4 Address Space,
LACNIC Policy Manual:
https://www.lacnic.net/innovaportal/file/680/1/manual-politicas-en-2-21.pdf
<https://www.lacnic.net/innovaportal/file/680/1/manual-politicas-en-2-21.pdf>
Regards,
Bikram, Shaila, and Ching-Heng
APNIC Policy SIG Chairs
_______________________________________________
SIG-policy -https://mailman.apnic.net/[email protected]/
<https://mailman.apnic.net/[email protected]/>
To unsubscribe send an email [email protected]
<mailto:[email protected]>
_______________________________________________
SIG-policy - https://mailman.apnic.net/[email protected]/
To unsubscribe send an email to [email protected]
https://jon.brewer.nz/
_______________________________________________
SIG-policy -https://mailman.apnic.net/[email protected]/
To unsubscribe send an email [email protected]
_______________________________________________
SIG-policy - https://mailman.apnic.net/[email protected]/
To unsubscribe send an email to [email protected]
