Hi,
It's regular contribution from JPOPF Steering Team to summarize the discussion
there with regard to the current policy proposals up for the forthcoming
policy-sig on-site discussion.
I am writing this message since we had an increased interest for Address Policy
in NIRs and to put spotlight on his messages as an NIR policy forum's effort to
reach out in-country community to discuss policy proposals in APNIC policy-sig,
which is in order to maintain policies in APNIC and JPNIC consistent.
Another point worth your interest would be that it is not a voice from a single
person but a discussion summary out of Japanese Policy Forum, although not so
many people involved in the discussion.
Thank you Tsurumaki-san and colleagues at JPOPF ST for this regular
contribution.
Thank you,
MAEMURA Akinori, JPNIC
On 2024/02/07 18:03, Satoru Tsurumaki wrote:
Dear Colleagues,
I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..
I would like to share key feedback in our community for prop-154,based
on a meeting we organised on 31th Jan to discuss these proposals.
This feedback is sent on my behalf, but please note that it is a
summary of the discussions among the 12 Japanese community members (5
on-site, 7 remote) who attended the meeting.
Many oppose opinions were expressed about this proposal.
In particular, many participants share the view that the IPv4 address
savings to be gained from this proposal are not worth the effort
related to renumbering that many IXP stakeholders will have to bear.
(comment details)
- The number of IPv4 addresses that are expected to be saved by this
proposal should be indicated in detail.
- It was pointed out in APNIC 56 that the effort related to
renumbering is very burdensome for IXP and IXP's customers, and I
oppose this proposal because it is not considered about it at all in
this proposal.
Regards,
2023年9月9日(土) 8:07 Shaila Sharmin <shaila.sharmin....@gmail.com>:
Dear SIG members,
A new version of the proposal "prop-154: Resizing of IPv4 assignment for
the IXPs"
has been sent to the Policy SIG for review.
Information about earlier versions is available from:
http://www.apnic.net/policy/proposals/prop-154
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.
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v002: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sba...@gmail.com)
Aftab Siddiqui
1. Problem statement
--------------------
According to APNIC Internet Number Resource Policies ( Ref – APNIC-127,
Dated: 22 DEC, 2022 ), an Internet Exchange Point ( IXP ) is eligible to
receive a maximum /23 of IPv4 and /48 of IPv6 resources. Usually APNIC
assign one /24 to start a new IXP. But from analysis through PeeringDB,
we found most of places the resources have been underutilized and new
IXPs are wasting a large amount of valuable IPv4 space. On the other
side there are large IXP, who can’t grow due to lack of IP resources,
where /23 is not enough as the membership size is big. The size of the
minimum and maximum range of IP delegation to new or existing IXPs is
the main problem in the current policy.
Present IXP Status in APAC region from PeeringDB [5] :
+-------------------+-------+------------+-------+---------------------------+
| IX Names | Peers | ....Vs.... | Peers | IX
Names |
+-------------------+-------+ +-------+---------------------------+
| BBIX Tokyo | 299 | | 17 |
BBIX-Thailand |
+-------------------+-------+ +-------+---------------------------+
| JPIX TOKYO | 257 | | 3 |
MekongIX |
+-------------------+-------+ +-------+---------------------------+
| Equinix Tokyo | 131 | | 2 | Equinix
Mumbai |
+-------------------+-------+ +-------+---------------------------+
| JPNAP Tokyo | 211 | | 13 | npIX
JWL |
+-------------------+-------+ +-------+---------------------------+
| HKIX | 296 | | 3 | Vanuatu Internet
Exchange |
+-------------------+-------+ +-------+---------------------------+
| Equinix Hong Kong | 216 | | 4 |
MyNAP |
+-------------------+-------+ +-------+---------------------------+
| Equinix Singapore | 422 | | 25 | DE-CIX Kuala
Lumpur |
+-------------------+-------+ +-------+---------------------------+
| IIX-Jakarta | 449 | | 13 |
IIX-Lampung |
+-------------------+-------+ +-------+---------------------------+
| DECIX-Mumbai | 446 | | 14 | Decix
Kolkata |
+-------------------+-------+ +-------+---------------------------+
| MegaIX Sydney | 232 | | 46 | EdgeIX -
Melbourne |
+-------------------+-------+------------+-------+---------------------------+
2. Objective of policy change
-----------------------------
The objective of this proposal is to modify the default size of IPv4
assignments for IXPs from up to /23 to /26, which can receive a
replacement up to a maximum of a /22, provided the IXP returns the IPv4
address space previously assigned to them.
3. Situation in other regions
-----------------------------
Similar policy has been adopted by RIPE NCC ( ripe-733 : IPv4 Address
Allocation and Assignment Policies for the RIPE NCC Service Region ) [4]
4. Proposed policy solution
---------------------------
Current Policy text :
6.2.4. IPv4 for Internet Exchange Points
Internet Exchange Points (IXP) are eligible to receive a delegation from
APNIC to be used exclusively to connect the IXP participant devices to
the Exchange Point.
Global routability of the delegation is left to the discretion of the
IXP and its participants.
New Policy text :
6.2.4. IPv4 for Internet Exchange Points
By default, a /26 of IPv4 address block will be assigned to the new IXPs.
IXPs can seek an assignment of up to a /25 when they can justify having
more than 60 peers on the IXP fabric (peering LAN) in the next 12 months.
IXPs can seek an assignment of up to a /23 or current highest assignment
size when they can justify having more than 100 peers on the IXP fabric
(peering LAN) in the next 12 months.
An IXP which received an assignment less than /24 can request up to /23
IPv4, only if 60% of the original assignment has been used. The existing
assignment must be returned by the IXP within 3 months of the new
assignment.
Existing Large IXPs that already have used their maximum assignment of
/23 from current policy can request a contiguous block (if available) of
/22, only if they have already used 60% of existing assignment. The
existing assignment must be returned by the IXP within 3 months of the
new assignment.
Any existing IXP that wants to open new POPs can request for more IPv4
addresses (which will be allocated using the same principle as defined
above /26 and /25) as long as the total allocation doesn’t exceed /22.
Any resources assigned under this policy will not be announced in the
global routing table (mistakes are exempted) and must be used for IXP
peering only, in case otherwise the resources will be revoked by APNIC.
Global routability of the delegation outside this policy is left to the
discretion of the IXP and its participants.
Any resources assigned under this policy will be non-transferable.
Recommendation - APNIC should reserve up to /20 for IXPs under this policy
5. Advantages / Disadvantages
-----------------------------
Advantages:
This proposal will ensure rapid expansion of IXPs in terms of membership
and POP numbers for this region and smoothen allocation of IPv4.
Reducing the default assignment size to /26 would stop wasting a large
amount of valuable IPv4 space. Increasing the allocation size will help
the IXPs add more members in fabric very easily.
Disadvantages:
When the IXP operator jumps into a bigger block of IPv4 and returns the
existing one, then they might be required to renumber all routers
connected to that IXP fabric (peering LAN).
6. Impact on APNIC
------------------
The IXP who already became an APNIC member and has less IPv4 Resources
can also apply for maximum delegation for their expansion.
7. References
-------------
[1] Section 6.2.4. IPv4 for Internet Exchange Points.
https://www.apnic.net/community/policy/resources#a_h_6_2_4
[2] Section 9.1.3. IPv6 for Internet Exchange Points.
https://www.apnic.net/community/policy/resources#a_h_9_1_3
[3] Section 11.1.2. Conditions on source of the transfer
https://www.apnic.net/community/policy/resources#a_h_11_1
[4] IPv4 Address Allocation and Assignment Policies for the RIPE NCC
Service Region https://www.ripe.net/publications/docs/ripe-733
[5] PeeringDB : https://www.peeringdb.com/
_______________________________________________
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net
_______________________________________________
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net
_______________________________________________
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net
