Oppose.
Rearranging deck chairs to smaller ixp prefixes is a step away from goodness.
I do support removing the /23 cap for IXPs that demonstrate need for shorter prefixes.
I do not support RIR assignments or allocations longer than /24 in IPv4 or /48 in IPv6.
When we run out, IXPs can move to v6only. The providers on the exchange points can still exchange IPv4 NLRI via IPv6 peering sessions and forward IPv4 data grams to the correct MAC next-hop learned via IPv6 ND.
This is already in widespread use. It’s a bit hacking, but it works and doesn’t require additional IPv4 addresses.
Owen
Dear SIG members,A new proposal "prop-154-v001: Resizing of IPv4 assignment for the IXPs" has been sent to the Policy SIG for review.It will be presented at the Open Policy Meeting (OPM) at APNIC 56 on Thursday, 14 September 2023. https://conference.apnic.net/56/program/program/#/day/8/We invite you to review and comment on the proposal on the mailing list before the OPM.The comment period on the mailing list before the OPM is an important part of the Policy Development Process (PDP). 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?Information about this proposal is appended below as well as available at: http://www.apnic.net/policy/proposals/prop-154Regards,Bertrand, Shaila, and AnupamAPNIC Policy SIG Chairs---------------------------------------------------------------prop-154-v001: Resizing of IPv4 assignment for the IXPs----------------------------------------------------------------Proposer: Simon Sohel Baroi ([email protected]) Aftab Siddiqui1. 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 /23of IPv4 and /48 of IPv6resources. Usually APNIC assign one /24 to start a new IXP. But fromanalysis through PeeringDB,we found most of the places the resources have been under-utilised and newIXPs are wasting a largeamount of valuable IPv4 spaces. On the other side there are large IXP,who can’t grow due tolack of IP resources, where /23 is not enough as the membership numberis big. The size of theminimum and maximum range of IP delegation to new or existing IXPs isthe main problem in thecurrent policy.Present IXP Status in APAC region from PeeringDB [5] :+-------------------+-------+------------+-------+---------------------------+| IX Names | Peers | ....Vs.... | Peers | IXNames |+-------------------+-------+ +-------+---------------------------+| BBIX Tokyo | 299 | | 17 |BBIX-Thailand |+-------------------+-------+ +-------+---------------------------+| JPIX TOKYO | 257 | | 3 |MekongIX |+-------------------+-------+ +-------+---------------------------+| Equinix Tokyo | 131 | | 2 | EquinixMumbai |+-------------------+-------+ +-------+---------------------------+| JPNAP Tokyo | 211 | | 13 | npIXJWL |+-------------------+-------+ +-------+---------------------------+| HKIX | 296 | | 3 | Vanuatu InternetExchange |+-------------------+-------+ +-------+---------------------------+| Equinix Hong Kong | 216 | | 4 |MyNAP |+-------------------+-------+ +-------+---------------------------+| Equinix Singapore | 422 | | 25 | DE-CIX KualaLumpur |+-------------------+-------+ +-------+---------------------------+| IIX-Jakarta | 449 | | 13 |IIX-Lampung |+-------------------+-------+ +-------+---------------------------+| DECIX-Mumbai | 446 | | 14 | DecixKolkata |+-------------------+-------+ +-------+---------------------------+| MegaIX Sydney | 232 | | 46 | EdgeIX -Melbourne |+-------------------+-------+------------+-------+---------------------------+2. Objective of policy change-----------------------------The objective of this proposal is to modify the default size of IPv4assignments for IXPsfrom /23 to /26, which can receive a replacement up to a maximum of a/22, provided theIXP 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 AddressAllocation andAssignment Policies for the RIPE NCC Service Region ) [4]4. Proposed policy solution---------------------------Current Policy text:6.2.4. IPv4 for Internet Exchange PointsInternet Exchange Points (IXP) are eligible to receive a delegation fromAPNIC to be usedexclusively to connect the IXP participant devices to the Exchange Point.Global routability of the delegation is left to the discretion of theIXP and its participants.New Policy text:6.2.4. IPv4 for Internet Exchange PointsBy 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 havingmore than 60 peerson the IXP fabric (peering LAN) in the next 12 months.IXPs can seek an assignment of up to a /24 when they can justify havingmore than 100 peers onthe IXP fabric (peering LAN) in the next 12 months.If it is a national IXP and the said economy doesn’t have more than 60registered APNIC membersor resource holders (from other RIRs or legacy space holders) then thereis no justification tohave more than /27 assignments.An IXP which received an assignment less than /24 can request upto /23IPv4, only if 60% ofthe original assignment has been used. The existing assignment must bereturned by the IXPwithin 3 months of the new assignment.Existing Large IXPs that already have used their maximum assignment of/23 from current policy canrequest a contiguous block (if available) of /22, only if they havealready used 80% of existingassignments. The existing assignment must be returned by the IXP within 3months of the new assignment.Any resources less than /24 assigned under this policy will not beannounced in the global routing table(mistakes are exempted) and must be used for IXP peering only, in caseotherwise the resources will berevoked by APNIC.Global routability of the delegation outside this policy is left to thediscretion of the IXP and itsparticipants.5. Advantages / Disadvantages-----------------------------Advantages:This proposal will ensure rapid expansion of IXPs in terms of membershipand PoP numbers for this regionand smoothen allocation of IPv4. Reducing the default assignment size to/26 would stop wasting a largeamount of valuable IPv4 space.Disadvantages:When the IXP operator jumps into a bigger block of IPv4 and returns theexisting one, then they might berequired 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 Resourcescan also apply for maximum delegationfor their expansion.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 transferhttps://www.apnic.net/community/policy/resources#a_h_11_1[4] IPv4 Address Allocation and Assignment Policies for the RIPE NCCService Regionhttps://www.ripe.net/publications/docs/ripe-733[5] PeeringDBhttps://www.peeringdb.com/
|
