Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
8 Aug
2023
4:11 a.m.
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).
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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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/
- 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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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/
13
23
Replies
8 Aug
10:51 p.m.
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
On Aug 7, 2023, at 21:14, Shaila Sharmin <shaila.sharmin.ovi@gmail.com> wrote:
_______________________________________________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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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-leave@lists.apnic.net
10 Aug
1:17 p.m.
Hi Owen,
When we run out, IXPs can move to v6only.
"When we run out" - we still have a couple of million IPv4 address space. When some RIRs ran out, it created an open market. Transfers and M&A are still happening and continue to happen, let's wisely use and allocate the resources.
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.
Can you give me an example of IXP where the peering lan is IPv6 only?
Owen
Aftab A. Siddiqui
10 Aug
3:34 p.m.
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.Can you give me an example of IXP where the peering lan is IPv6 only?
Point is that an IXP doesn’t technically need IPv4 addresses on the IX in order to support dual stack peering sessions. It’s a nice to have and less confusing to have v4 over v4 and v6 over v6, but when we run out of v4 addresses for IXPs, that won’t be as painful as, say not being able to put v4 addresses on web servers or DNS servers.
Owen
OwenRegards,
Aftab A. Siddiqui
9 Aug
3:47 a.m.
Shaila,
I oppose this, but not because of its details.
We (Operators) cannot have it both ways. We have been screaming that IPv4 is over, since at least 2011. Slicing it finer extends the pain, as well as demonstrates to everyone that IPv4 is still a valuable, and required, commodity.
Issue what we have. Then stop. Let us not micromanage this.
On Tue, Aug 8, 2023 at 12:12 PM Shaila Sharmin <shaila.sharmin.ovi@gmail.com> wrote:
_______________________________________________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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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-leave@lists.apnic.net
10 Aug
1:08 p.m.
Hi Sanjeev bhai :) always good to hear from you.
On Wed, 9 Aug 2023 at 13:48, Sanjeev Gupta <sanjeev@dcs1.biz> wrote:
Shaila,I oppose this, but not because of its details.We (Operators) cannot have it both ways. We have been screaming that IPv4 is over, since at least 2011. Slicing it finer extends the pain, as well as demonstrates to everyone that IPv4 is still a valuable, and required, commodity.
You know that I absolutely don't disagree with this point, as someone who started the IPv6 Task Force PK 15yrs still very much enthusiastic about the "IPv6 only" world but the reality is that it's not going to happen most likely in my lifetime. Whether we like it or not, IPv4 is still required and we just have to make best use of the remaining resources. As you are very much aware of the situation in this region, most likely ten or so IXPs in the next decade will use /26 or /25 allocations under this policy but probably another 10 or so will take the benefit of /22 allocations for expansion. For the later, the only way for them to expand is to get/purchase resources from the open market. This policy is actually giving away IPv4 addresses to those who needs it and get over with it.
Issue what we have. Then stop. Let us not micromanage this.
A little bit more micro-management for a few more years and we will be over with the last /8. Last time I did the forecast it was around 2025/26 when we were running out of it, this policy will not change that.
Regards,
Aftab A. Siddiqui
Aftab A. Siddiqui
9 Aug
7:17 a.m.
Hi Shaila,
I oppose this proposal. Expansion of IXPs in terms of Membership and PoPs depend upon factors of market dynamics like availability of ISPs, CDNs and Telcos at a particular region where new IXP is to be planned and set up. The proposal in no way promote or help in IXP expansion.
Further there are IXPs which still operate in L3 architecture and require bigger chunk of IP subnets for their operations. Restricting the default size of IP assignments from /23 to /26 will further delay and hamper the operations.
Almost all the IXPs are dual stack (IPv4 and IPv6) and run BGP configurations of v6 as well . So this proposal is irrelevant for IXPs.
Regards.
Abhishek Gautam
+919703728000
On Tue, Aug 8, 2023 at 9:42 AM Shaila Sharmin <shaila.sharmin.ovi@gmail.com> wrote:
_______________________________________________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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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-leave@lists.apnic.net
10 Aug
12:59 p.m.
Hi Abhishek,
I oppose this proposal. Expansion of IXPs in terms of Membership and PoPs depend upon factors of market dynamics like availability of ISPs, CDNs and Telcos at a particular region where new IXP is to be planned and set up. The proposal in no way promote or help in IXP expansion.
You are right, the membership of an IXP depends upon the availability of ISPs, CDNs and Telcos in that economy. There are 56 economies in the APINC service region, out of those 33 economies have less than 50 ASNs delegated to them, even if you add handful of CDNs and/or foreign networks who wants to peer in that IX, you are still pretty much covered with a single IPv4 /26.
Further there are IXPs which still operate in L3 architecture and require bigger chunk of IP subnets for their operations.
First of all, no IXP should operate in L3 architecture. Secondly, the proposal is not stopping any IXP to operate with a bigger IPv4 allocation if they can justify it. APNIC still requires you to provide justification of use even today.
Restricting the default size of IP assignments from /23 to /26 will further delay and hamper the operations.
How? Can you please provide some examples?
Almost all the IXPs are dual stack (IPv4 and IPv6) and run BGP configurations of v6 as well . So this proposal is irrelevant for IXPs.
Dual stack means IPv4 and IPv6, you still need v4 to make it "Dual" stack. I'm still struggling to understand what is the correlation? If you are making the point which Sanjeev and Owen made then I totally agree but they are not talking about dual stack.
Regards.Abhishek Gautam+919703728000
11 Aug
3:23 a.m.
Hi Aftab,
Dual stack network enables service providers(ISPs,IXPs, Telcos etc.) to serve their customers with both IPv4 and IPv6. Even service providers can decide to transform their customers from v4 to v6. So this policy doesn't make any difference as sooner or later most of IXPs serve customers with v6 while retaining the v4(in case not yet transformed).
Regards.
Abhishek Gautam
+919703728000
On Thu, Aug 10, 2023 at 6:29 PM Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:
Hi Abhishek,I oppose this proposal. Expansion of IXPs in terms of Membership and PoPs depend upon factors of market dynamics like availability of ISPs, CDNs and Telcos at a particular region where new IXP is to be planned and set up. The proposal in no way promote or help in IXP expansion.You are right, the membership of an IXP depends upon the availability of ISPs, CDNs and Telcos in that economy. There are 56 economies in the APINC service region, out of those 33 economies have less than 50 ASNs delegated to them, even if you add handful of CDNs and/or foreign networks who wants to peer in that IX, you are still pretty much covered with a single IPv4 /26.Further there are IXPs which still operate in L3 architecture and require bigger chunk of IP subnets for their operations.First of all, no IXP should operate in L3 architecture. Secondly, the proposal is not stopping any IXP to operate with a bigger IPv4 allocation if they can justify it. APNIC still requires you to provide justification of use even today.Restricting the default size of IP assignments from /23 to /26 will further delay and hamper the operations.How? Can you please provide some examples?Almost all the IXPs are dual stack (IPv4 and IPv6) and run BGP configurations of v6 as well . So this proposal is irrelevant for IXPs.Dual stack means IPv4 and IPv6, you still need v4 to make it "Dual" stack. I'm still struggling to understand what is the correlation? If you are making the point which Sanjeev and Owen made then I totally agree but they are not talking about dual stack.Regards.Abhishek Gautam+919703728000
10 Aug
2:15 a.m.
Dear Concern;
Greetings from NIX-BD !!!
Good luck with a new proposal "prop-154-v001. Resizing the IPv4 assignment for IXPs should get input from those who have worked in the practical field. IXP is a small field but its vision works on a much larger scale. In terms of PoP-expansion of IXPs depends on market dynamics factors such as availability of ISPs, CDNs and Telcos. such as in marginal areas where new IXPs will be planned and set up. The proposal does not in any way promote or assist in the expansion of IXP. The default size of IP assignments cannot be /23 to /26 by any means. So this proposal is irrelevant for IXP.Please feel free to contact us for any further information in this regard.
With Kinds Regards
------------------------------
Md Alamgir Kabir
ISPAB-NIX
Mobile Number # +880-1711435267
Skype# kabirrana5
On Tue, Aug 8, 2023 at 10:12 AM Shaila Sharmin <shaila.sharmin.ovi@gmail.com> wrote:
_______________________________________________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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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-leave@lists.apnic.net
10 Aug
3:51 p.m.
Alamgir Vai,
Thanks for your valuable inputs and comments.
IXP is a small field but its vision works on a much larger
scale. In terms of PoP-expansion of IXPs depends on market dynamics
factors such as availability of ISPs, CDNs and Telcos. such as in marginal
areas where new IXPs will be planned and set up.
-> IXP plays a crucial role in Internet architecture.But among the 56 economies, not all markets are the same. Some small and some are big. A new IX has the potential to grow quickly and handle heavy traffic. IXPAB-NIX (NIX-BD) is an excellent instance. We made an effort to provide a step-up approach so that IXPs may expand quickly. Additionally, new IXPs should not waste unused IPv4 Resources.
Today, obtaining IPV4 resources is fairly simple;however, tomorrow may be different.
-> IXP plays a crucial role in Internet architecture.But among the 56 economies, not all markets are the same. Some small and some are big. A new IX has the potential to grow quickly and handle heavy traffic. IXPAB-NIX (NIX-BD) is an excellent instance. We made an effort to provide a step-up approach so that IXPs may expand quickly. Additionally, new IXPs should not waste unused IPv4 Resources.
Today, obtaining IPV4 resources is fairly simple;however, tomorrow may be different.
The proposal does not in any way promote or assist in the expansion of IXP. The default size of IP assignments cannot be /23 to /26 by any means.
-> The proposal allows the IXPs to grow bigger and get upto /22, where the present policy is limited to /23. According to the expansion of IXPs in the area, all national level IXPs will soon need those kinds of resources.
On Thu, Aug 10, 2023 at 8:15 AM Md Alamgir Kabir <kabirrana5@gmail.com> wrote:
Dear Concern;Greetings from NIX-BD !!!Good luck with a new proposal "prop-154-v001. Resizing the IPv4 assignment for IXPs should get input from those who have worked in the practical field. IXP is a small field but its vision works on a much larger scale. In terms of PoP-expansion of IXPs depends on market dynamics factors such as availability of ISPs, CDNs and Telcos. such as in marginal areas where new IXPs will be planned and set up. The proposal does not in any way promote or assist in the expansion of IXP. The default size of IP assignments cannot be /23 to /26 by any means. So this proposal is irrelevant for IXP.Please feel free to contact us for any further information in this regard.With Kinds Regards------------------------------Md Alamgir KabirISPAB-NIXMobile Number # +880-1711435267Skype# kabirrana5_______________________________________________On Tue, Aug 8, 2023 at 10:12 AM Shaila Sharmin <shaila.sharmin.ovi@gmail.com> wrote:_______________________________________________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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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-leave@lists.apnic.net
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-leave@lists.apnic.net
Simon Sohel Baroi | 45/c Senpara Parbata, Mirpur-10, Dhaka-1216 |
Cell : +880-184-7102243 | Viber / Cell : +880-181-7022207 |
Cell : +880-184-7102243 | Viber / Cell : +880-181-7022207 |
Mail : sbaroi@gmail.com | Skype : tx.fttx |
Reduce. Reuse. Recycle. Respect. It's the little things that really can make a difference.
11 Aug
6:33 a.m.
Dear concern;
Assalamu Alaikum
Greetings from ISPAB-NIX !!!All IXPs in the world need an experienced representation of how they operate.
Then the idea of IPv4 can be found in IXP. IXP started in Bangladesh in 2004. In terms of development, we need to have a plan on what kind of IXP sustainability should be in our country. Along with that, we should think about expanding content delivery network (CDN) to IXPs in our country. Expanding thinking /23, /22 is not enough. IXPAB-NIX is planning on that. IPV4 growth needs to be corrected.Please feel free to contact us for any further information in this regard.
With Kinds Regards
------------------------------
NIX-KABIR
Mobile Number # +880-1711435267
Skype# kabirrana5
On Thu, Aug 10, 2023 at 9:51 PM Simon Sohel Baroi <sbaroi@gmail.com> wrote:
Alamgir Vai,Thanks for your valuable inputs and comments.IXP is a small field but its vision works on a much larger scale. In terms of PoP-expansion of IXPs depends on market dynamics factors such as availability of ISPs, CDNs and Telcos. such as in marginal areas where new IXPs will be planned and set up.
-> IXP plays a crucial role in Internet architecture.But among the 56 economies, not all markets are the same. Some small and some are big. A new IX has the potential to grow quickly and handle heavy traffic. IXPAB-NIX (NIX-BD) is an excellent instance. We made an effort to provide a step-up approach so that IXPs may expand quickly. Additionally, new IXPs should not waste unused IPv4 Resources.
Today, obtaining IPV4 resources is fairly simple;however, tomorrow may be different.
The proposal does not in any way promote or assist in the expansion of IXP. The default size of IP assignments cannot be /23 to /26 by any means.
-> The proposal allows the IXPs to grow bigger and get upto /22, where the present policy is limited to /23. According to the expansion of IXPs in the area, all national level IXPs will soon need those kinds of resources.
On Thu, Aug 10, 2023 at 8:15 AM Md Alamgir Kabir <kabirrana5@gmail.com> wrote:Dear Concern;Greetings from NIX-BD !!!Good luck with a new proposal "prop-154-v001. Resizing the IPv4 assignment for IXPs should get input from those who have worked in the practical field. IXP is a small field but its vision works on a much larger scale. In terms of PoP-expansion of IXPs depends on market dynamics factors such as availability of ISPs, CDNs and Telcos. such as in marginal areas where new IXPs will be planned and set up. The proposal does not in any way promote or assist in the expansion of IXP. The default size of IP assignments cannot be /23 to /26 by any means. So this proposal is irrelevant for IXP.Please feel free to contact us for any further information in this regard.With Kinds Regards------------------------------Md Alamgir KabirISPAB-NIXMobile Number # +880-1711435267Skype# kabirrana5_______________________________________________On Tue, Aug 8, 2023 at 10:12 AM Shaila Sharmin <shaila.sharmin.ovi@gmail.com> wrote:_______________________________________________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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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-leave@lists.apnic.net
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-leave@lists.apnic.net--Simon Sohel Baroi | 45/c Senpara Parbata, Mirpur-10, Dhaka-1216 |
Cell : +880-184-7102243 | Viber / Cell : +880-181-7022207 |Mail : sbaroi@gmail.com | Skype : tx.fttx |Reduce. Reuse. Recycle. Respect. It's the little things that really can make a difference.
13 Aug
11:59 p.m.
Hi Alamgir,
I'm not sure what you are suggesting here, firstly we are not discussing the IXP sustainability though it's a nice topic but of course out of the scope of policy discussion and certainly the proposed policy. The policy does actually provide provision to have up to /22 allocation if an IXP reaches 80% utilization which lets say is 400 Peers. Right now ISPAB-NIX (Bangladesh Internet Service Provider Internet Exchange Trust) has a /23 (103.161.216./23) IPv4 and /32 (2407:840::/32) IPv6 allocation, from the peeringdb stats it shows there are only 51 peers even the record is not up to date and giving benefit of doubt lets say there are 100 peers, but still there is no way to have more than 400 peers in the near future and even if that happens then you can still get /22 with the new policy.
Would you like to elaborate further the reservations you have?
Regards,
Aftab A. Siddiqui
Aftab A. Siddiqui
On Fri, 11 Aug 2023 at 16:34, Md Alamgir Kabir <kabirrana5@gmail.com> wrote:
Dear concern;Assalamu AlaikumGreetings from ISPAB-NIX !!!
All IXPs in the world need an experienced representation of how they operate.
Then the idea of IPv4 can be found in IXP. IXP started in Bangladesh in 2004. In terms of development, we need to have a plan on what kind of IXP sustainability should be in our country. Along with that, we should think about expanding content delivery network (CDN) to IXPs in our country. Expanding thinking /23, /22 is not enough. IXPAB-NIX is planning on that. IPV4 growth needs to be corrected.Please feel free to contact us for any further information in this regard.With Kinds Regards------------------------------NIX-KABIRMobile Number # +880-1711435267Skype# kabirrana5_______________________________________________On Thu, Aug 10, 2023 at 9:51 PM Simon Sohel Baroi <sbaroi@gmail.com> wrote:Alamgir Vai,Thanks for your valuable inputs and comments.IXP is a small field but its vision works on a much larger scale. In terms of PoP-expansion of IXPs depends on market dynamics factors such as availability of ISPs, CDNs and Telcos. such as in marginal areas where new IXPs will be planned and set up.
-> IXP plays a crucial role in Internet architecture.But among the 56 economies, not all markets are the same. Some small and some are big. A new IX has the potential to grow quickly and handle heavy traffic. IXPAB-NIX (NIX-BD) is an excellent instance. We made an effort to provide a step-up approach so that IXPs may expand quickly. Additionally, new IXPs should not waste unused IPv4 Resources.
Today, obtaining IPV4 resources is fairly simple;however, tomorrow may be different.
The proposal does not in any way promote or assist in the expansion of IXP. The default size of IP assignments cannot be /23 to /26 by any means.
-> The proposal allows the IXPs to grow bigger and get upto /22, where the present policy is limited to /23. According to the expansion of IXPs in the area, all national level IXPs will soon need those kinds of resources.
On Thu, Aug 10, 2023 at 8:15 AM Md Alamgir Kabir <kabirrana5@gmail.com> wrote:Dear Concern;Greetings from NIX-BD !!!Good luck with a new proposal "prop-154-v001. Resizing the IPv4 assignment for IXPs should get input from those who have worked in the practical field. IXP is a small field but its vision works on a much larger scale. In terms of PoP-expansion of IXPs depends on market dynamics factors such as availability of ISPs, CDNs and Telcos. such as in marginal areas where new IXPs will be planned and set up. The proposal does not in any way promote or assist in the expansion of IXP. The default size of IP assignments cannot be /23 to /26 by any means. So this proposal is irrelevant for IXP.Please feel free to contact us for any further information in this regard.With Kinds Regards------------------------------Md Alamgir KabirISPAB-NIXMobile Number # +880-1711435267Skype# kabirrana5_______________________________________________On Tue, Aug 8, 2023 at 10:12 AM Shaila Sharmin <shaila.sharmin.ovi@gmail.com> wrote:_______________________________________________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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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-leave@lists.apnic.net
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-leave@lists.apnic.net--Simon Sohel Baroi | 45/c Senpara Parbata, Mirpur-10, Dhaka-1216 |
Cell : +880-184-7102243 | Viber / Cell : +880-181-7022207 |Mail : sbaroi@gmail.com | Skype : tx.fttx |Reduce. Reuse. Recycle. Respect. It's the little things that really can make a difference.
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-leave@lists.apnic.net
14 Aug
5:01 a.m.
Dear Concern ;
Assalamu Alaikum
Greetings from NIX-BD !!!
I'm not really suggesting it. PeeringDB had a nice talk about the stats, showing 51 peers not all logged into peering db. Hope everyone will enter the peering DB. Bangladesh internet service provider internet company 2500 plus and more ASN in Bangladesh.I hope you understand. Please feel free to contact us for any further information in this regard.
With Kinds Regards
------------------------------
NIX KABIR
Mobile Number # +880-1711435267
Skype# kabirrana5
On Mon, Aug 14, 2023 at 5:59 AM Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:
Hi Alamgir,I'm not sure what you are suggesting here, firstly we are not discussing the IXP sustainability though it's a nice topic but of course out of the scope of policy discussion and certainly the proposed policy. The policy does actually provide provision to have up to /22 allocation if an IXP reaches 80% utilization which lets say is 400 Peers. Right now ISPAB-NIX (Bangladesh Internet Service Provider Internet Exchange Trust) has a /23 (103.161.216./23) IPv4 and /32 (2407:840::/32) IPv6 allocation, from the peeringdb stats it shows there are only 51 peers even the record is not up to date and giving benefit of doubt lets say there are 100 peers, but still there is no way to have more than 400 peers in the near future and even if that happens then you can still get /22 with the new policy.Would you like to elaborate further the reservations you have?Regards,
Aftab A. SiddiquiOn Fri, 11 Aug 2023 at 16:34, Md Alamgir Kabir <kabirrana5@gmail.com> wrote:Dear concern;Assalamu AlaikumGreetings from ISPAB-NIX !!!
All IXPs in the world need an experienced representation of how they operate.
Then the idea of IPv4 can be found in IXP. IXP started in Bangladesh in 2004. In terms of development, we need to have a plan on what kind of IXP sustainability should be in our country. Along with that, we should think about expanding content delivery network (CDN) to IXPs in our country. Expanding thinking /23, /22 is not enough. IXPAB-NIX is planning on that. IPV4 growth needs to be corrected.Please feel free to contact us for any further information in this regard.With Kinds Regards------------------------------NIX-KABIRMobile Number # +880-1711435267Skype# kabirrana5_______________________________________________On Thu, Aug 10, 2023 at 9:51 PM Simon Sohel Baroi <sbaroi@gmail.com> wrote:Alamgir Vai,Thanks for your valuable inputs and comments.IXP is a small field but its vision works on a much larger scale. In terms of PoP-expansion of IXPs depends on market dynamics factors such as availability of ISPs, CDNs and Telcos. such as in marginal areas where new IXPs will be planned and set up.
-> IXP plays a crucial role in Internet architecture.But among the 56 economies, not all markets are the same. Some small and some are big. A new IX has the potential to grow quickly and handle heavy traffic. IXPAB-NIX (NIX-BD) is an excellent instance. We made an effort to provide a step-up approach so that IXPs may expand quickly. Additionally, new IXPs should not waste unused IPv4 Resources.
Today, obtaining IPV4 resources is fairly simple;however, tomorrow may be different.
The proposal does not in any way promote or assist in the expansion of IXP. The default size of IP assignments cannot be /23 to /26 by any means.
-> The proposal allows the IXPs to grow bigger and get upto /22, where the present policy is limited to /23. According to the expansion of IXPs in the area, all national level IXPs will soon need those kinds of resources.
On Thu, Aug 10, 2023 at 8:15 AM Md Alamgir Kabir <kabirrana5@gmail.com> wrote:Dear Concern;Greetings from NIX-BD !!!Good luck with a new proposal "prop-154-v001. Resizing the IPv4 assignment for IXPs should get input from those who have worked in the practical field. IXP is a small field but its vision works on a much larger scale. In terms of PoP-expansion of IXPs depends on market dynamics factors such as availability of ISPs, CDNs and Telcos. such as in marginal areas where new IXPs will be planned and set up. The proposal does not in any way promote or assist in the expansion of IXP. The default size of IP assignments cannot be /23 to /26 by any means. So this proposal is irrelevant for IXP.Please feel free to contact us for any further information in this regard.With Kinds Regards------------------------------Md Alamgir KabirISPAB-NIXMobile Number # +880-1711435267Skype# kabirrana5_______________________________________________On Tue, Aug 8, 2023 at 10:12 AM Shaila Sharmin <shaila.sharmin.ovi@gmail.com> wrote:_______________________________________________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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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-leave@lists.apnic.net
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-leave@lists.apnic.net--Simon Sohel Baroi | 45/c Senpara Parbata, Mirpur-10, Dhaka-1216 |
Cell : +880-184-7102243 | Viber / Cell : +880-181-7022207 |Mail : sbaroi@gmail.com | Skype : tx.fttx |Reduce. Reuse. Recycle. Respect. It's the little things that really can make a difference.
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-leave@lists.apnic.net
14 Aug
7:43 a.m.
Hi Alamgir,
Just for the sake of clarity, ISPAB-NIX already has a /23 IPv4 address block and if this IX wants to expand then prop-154 is actually providing a way to receive up to /22 i.e. 1024 IP addresses. Secondly, BD has 1811 ASN Delegations to-date so I'm not sure from where you got the 2500 plus number. Anyways, I still would like to hear your reasoning for opposing this policy
Regards,
Aftab A. Siddiqui
Aftab A. Siddiqui
On Mon, 14 Aug 2023 at 15:01, Md Alamgir Kabir <kabirrana5@gmail.com> wrote:
Dear Concern ;Assalamu AlaikumGreetings from NIX-BD !!!I'm not really suggesting it. PeeringDB had a nice talk about the stats, showing 51 peers not all logged into peering db. Hope everyone will enter the peering DB. Bangladesh internet service provider internet company 2500 plus and more ASN in Bangladesh.I hope you understand. Please feel free to contact us for any further information in this regard.With Kinds Regards------------------------------NIX KABIRMobile Number # +880-1711435267Skype# kabirrana5On Mon, Aug 14, 2023 at 5:59 AM Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:Hi Alamgir,I'm not sure what you are suggesting here, firstly we are not discussing the IXP sustainability though it's a nice topic but of course out of the scope of policy discussion and certainly the proposed policy. The policy does actually provide provision to have up to /22 allocation if an IXP reaches 80% utilization which lets say is 400 Peers. Right now ISPAB-NIX (Bangladesh Internet Service Provider Internet Exchange Trust) has a /23 (103.161.216./23) IPv4 and /32 (2407:840::/32) IPv6 allocation, from the peeringdb stats it shows there are only 51 peers even the record is not up to date and giving benefit of doubt lets say there are 100 peers, but still there is no way to have more than 400 peers in the near future and even if that happens then you can still get /22 with the new policy.Would you like to elaborate further the reservations you have?Regards,
Aftab A. SiddiquiOn Fri, 11 Aug 2023 at 16:34, Md Alamgir Kabir <kabirrana5@gmail.com> wrote:Dear concern;Assalamu AlaikumGreetings from ISPAB-NIX !!!
All IXPs in the world need an experienced representation of how they operate.
Then the idea of IPv4 can be found in IXP. IXP started in Bangladesh in 2004. In terms of development, we need to have a plan on what kind of IXP sustainability should be in our country. Along with that, we should think about expanding content delivery network (CDN) to IXPs in our country. Expanding thinking /23, /22 is not enough. IXPAB-NIX is planning on that. IPV4 growth needs to be corrected.Please feel free to contact us for any further information in this regard.With Kinds Regards------------------------------NIX-KABIRMobile Number # +880-1711435267Skype# kabirrana5_______________________________________________On Thu, Aug 10, 2023 at 9:51 PM Simon Sohel Baroi <sbaroi@gmail.com> wrote:Alamgir Vai,Thanks for your valuable inputs and comments.IXP is a small field but its vision works on a much larger scale. In terms of PoP-expansion of IXPs depends on market dynamics factors such as availability of ISPs, CDNs and Telcos. such as in marginal areas where new IXPs will be planned and set up.
-> IXP plays a crucial role in Internet architecture.But among the 56 economies, not all markets are the same. Some small and some are big. A new IX has the potential to grow quickly and handle heavy traffic. IXPAB-NIX (NIX-BD) is an excellent instance. We made an effort to provide a step-up approach so that IXPs may expand quickly. Additionally, new IXPs should not waste unused IPv4 Resources.
Today, obtaining IPV4 resources is fairly simple;however, tomorrow may be different.
The proposal does not in any way promote or assist in the expansion of IXP. The default size of IP assignments cannot be /23 to /26 by any means.
-> The proposal allows the IXPs to grow bigger and get upto /22, where the present policy is limited to /23. According to the expansion of IXPs in the area, all national level IXPs will soon need those kinds of resources.
On Thu, Aug 10, 2023 at 8:15 AM Md Alamgir Kabir <kabirrana5@gmail.com> wrote:Dear Concern;Greetings from NIX-BD !!!Good luck with a new proposal "prop-154-v001. Resizing the IPv4 assignment for IXPs should get input from those who have worked in the practical field. IXP is a small field but its vision works on a much larger scale. In terms of PoP-expansion of IXPs depends on market dynamics factors such as availability of ISPs, CDNs and Telcos. such as in marginal areas where new IXPs will be planned and set up. The proposal does not in any way promote or assist in the expansion of IXP. The default size of IP assignments cannot be /23 to /26 by any means. So this proposal is irrelevant for IXP.Please feel free to contact us for any further information in this regard.With Kinds Regards------------------------------Md Alamgir KabirISPAB-NIXMobile Number # +880-1711435267Skype# kabirrana5_______________________________________________On Tue, Aug 8, 2023 at 10:12 AM Shaila Sharmin <shaila.sharmin.ovi@gmail.com> wrote:_______________________________________________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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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-leave@lists.apnic.net
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-leave@lists.apnic.net--Simon Sohel Baroi | 45/c Senpara Parbata, Mirpur-10, Dhaka-1216 |
Cell : +880-184-7102243 | Viber / Cell : +880-181-7022207 |Mail : sbaroi@gmail.com | Skype : tx.fttx |Reduce. Reuse. Recycle. Respect. It's the little things that really can make a difference.
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-leave@lists.apnic.net
11 Aug
5:40 a.m.
Dear Community members,
I strongly oppose this proposal as there is no need to reduce further from /23, If one IX operator is going to open multiple IX nodes which are not inter-connected,the company needs more than /24 for each. I agree with Kabir and further suggest proposer to amend for increasing the size from /23 to /24 per Independent IX node for promoting the IX community.
Regards,
Ajai Kumar
On Thu, 10 Aug 2023 at 07:45, Md Alamgir Kabir <kabirrana5@gmail.com> wrote:
Dear Concern;Greetings from NIX-BD !!!Good luck with a new proposal "prop-154-v001. Resizing the IPv4 assignment for IXPs should get input from those who have worked in the practical field. IXP is a small field but its vision works on a much larger scale. In terms of PoP-expansion of IXPs depends on market dynamics factors such as availability of ISPs, CDNs and Telcos. such as in marginal areas where new IXPs will be planned and set up. The proposal does not in any way promote or assist in the expansion of IXP. The default size of IP assignments cannot be /23 to /26 by any means. So this proposal is irrelevant for IXP.Please feel free to contact us for any further information in this regard.With Kinds Regards------------------------------Md Alamgir KabirISPAB-NIXMobile Number # +880-1711435267Skype# kabirrana5_______________________________________________On Tue, Aug 8, 2023 at 10:12 AM Shaila Sharmin <shaila.sharmin.ovi@gmail.com> wrote:_______________________________________________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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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-leave@lists.apnic.net
SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-leave@lists.apnic.net
--
(M) +91-9868477444
Skype ID:erajay
P-mail: joinajay1 at gmail.com
.................................
Please don't print this email unless you really need to. This will preserve trees on our planet.
12 Aug
7:37 a.m.
Hello Team,
I support parts of this proposal, while I oppose others.
In some economies (to use Australia as an example), there are significant numbers of network operators. If an IXP were to start out and then have a requirement to re-number and expand, the bigger the IX becomes the harder it becomes to renumber. Let's look at MegaIX Sydney, and hypothesise that this policy was in place when they were reaching 80% utilisation (204 IP addresses) of a /24 subnet. It would be a significant challenge for all 204 peers, plus the route servers, to renumber and re-establish their peering sessions. The more peers you have, the harder it becomes.
Let's look at other economies such as Vanuatu, where they have such a small IX. I feel that in circumstances like this, it's not justifiable to allocate an entire /24 to an IX which has less than 5 peers. Given the size of the economy, it's unlikely (for the foreseeable future) that they will see requirements for anything greater than a /26 subnet.
Having said the above, we cannot discriminate economies based on the number of participants in delegating assignments. It may be better suited to restrict delegations to a /24 then if the need arises to renumber to a /23 they are given a 6-month window to return the former holding, and if they need to go from a /22 they are given 12 months. Whilst they hold these resources during the transition, they are responsible for any membership fees.
Regards, Christopher H.
13 Aug
5:07 a.m.
Renumbering an enterprise is hard.
Renumbering an IXP even a large one is relatively simple and has been done multiple times.
I still don’t support the proposal, but I think that the “renumbering is hard” argument rings a bit hollow when it comes to IXPs.
The process boils down to: 1. send out notice and map of old addresses to new addresses. 2. Add new addresses to route servers (if applicable) 3. Give time for providers to bring up all the new peering sessions on the new addresses (in parallel to the existing ones) 4. Turn off the peering sessions with the old addresses on the route servers (if applicable) 5. Set a flag day for turning off peering sessions on old addresses. 6. Filter TCP/179 traffic to old addresses on flag day. (let other traffic continue to pass) 7. Wait for traffic from deprecated peering sessions to drain off 8. Set a flag day to deprecate the old addresses 9. Filter the old addresses on the flag day.
Is it pain free? Not entirely, but relatively so. Main source of pain is providers that have to scramble after they ignore the flag day notices.
Is it particularly complicated or difficult? No, not really and if providers are paying attention and cooperate before the flag day, it can be non-disruptive and relatively pain free.
Owen
On Aug 12, 2023, at 00:37, Christopher H chris@thesysadmin.dev wrote:
Hello Team,
I support parts of this proposal, while I oppose others.
In some economies (to use Australia as an example), there are significant numbers of network operators. If an IXP were to start out and then have a requirement to re-number and expand, the bigger the IX becomes the harder it becomes to renumber. Let's look at MegaIX Sydney, and hypothesise that this policy was in place when they were reaching 80% utilisation (204 IP addresses) of a /24 subnet. It would be a significant challenge for all 204 peers, plus the route servers, to renumber and re-establish their peering sessions. The more peers you have, the harder it becomes.
Let's look at other economies such as Vanuatu, where they have such a small IX. I feel that in circumstances like this, it's not justifiable to allocate an entire /24 to an IX which has less than 5 peers. Given the size of the economy, it's unlikely (for the foreseeable future) that they will see requirements for anything greater than a /26 subnet.
Having said the above, we cannot discriminate economies based on the number of participants in delegating assignments. It may be better suited to restrict delegations to a /24 then if the need arises to renumber to a /23 they are given a 6-month window to return the former holding, and if they need to go from a /22 they are given 12 months. Whilst they hold these resources during the transition, they are responsible for any membership fees.
Regards, Christopher H. _______________________________________________ SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an email to sig-policy-leave@lists.apnic.net
13 Aug
11:35 p.m.
Hi Chris, thanks for your feedback.
On Sun, 13 Aug 2023 at 09:33, Christopher H <chris@thesysadmin.dev> wrote:
Hello Team,
I support parts of this proposal, while I oppose others.
In some economies (to use Australia as an example), there are significant numbers of network operators. If an IXP were to start out and then have a requirement to re-number and expand, the bigger the IX becomes the harder it becomes to renumber. Let's look at MegaIX Sydney, and hypothesise that this policy was in place when they were reaching 80% utilisation (204 IP addresses) of a /24 subnet. It would be a significant challenge for all 204 peers, plus the route servers, to renumber and re-establish their peering sessions. The more peers you have, the harder it becomes.
If I'm setting up an IX in Sydney today justifying a /23 is not a problem at all but as per the current text it says up to /24 for new allocations "IXPs can seek an assignment of up to a /24". But this can be updated to "IXPs can seek an assignment of up to a /23 or current highest allocation size provided they can provide justification". This change will address your concern
Let's look at other economies such as Vanuatu, where they have such a small IX. I feel that in circumstances like this, it's not justifiable to allocate an entire /24 to an IX which has less than 5 peers. Given the size of the economy, it's unlikely (for the foreseeable future) that they will see requirements for anything greater than a /26 subnet.
Having said the above, we cannot discriminate economies based on the number of participants in delegating assignments. It may be better suited to restrict delegations to a /24 then if the need arises to renumber to a /23 they are given a 6-month window to return the former holding, and if they need to go from a /22 they are given 12 months. Whilst they hold these resources during the transition, they are responsible for any membership fees.
I don't see it as a discrimination, an economy of less than half a million people can't have more than 15-20 ISPs or enterprises with their own networks, giving them the right amount of resources to establish and run the IXP is more important. While we are on the edge of IPv4 running out from the registry pool it's better to utilize them diligently and make sure everyone who needs it has some portion of it.
Second change I can propose is to "reserve /20 for small IXP allocations" so we can guarantee a fair allocation to smaller economies in the coming future.
Regards,
Christopher H.
Aftab A. Siddiqui
14 Aug
12:31 a.m.
Hi Aftab,
IXPs can seek an assignment of up to a /23 or current highest allocation size provided they can provide justification
Yes, this will address concerns for resource delegations in economies where there is a likely chance a /23 will be required.
In relation to economies with low numbers of peers, the reason I refer to it as discrimination is that according to the delegation criteria for IXPs, it states that the global routability of the delegation is left to the discretion of the IXP and its participants (ref: https://www.apnic.net/get-ip/get-ip-addresses-asn/). As we know, anything greater than a /24 (i.e. /25) is not globally routable, therefore it prevents IXPs in smaller economies from being able to route their IXP delegation if they wish to do so. It would be considered unreasonable to allow economies that have justifications of a /24 or larger to route their delegations, whereas those with a /25 or smaller cannot. We would either need to restrict all IXPs from globally routing their delegations, or continue to allow IXPs from smaller economies to obtain a /24 (at most).
Regards, Christopher H.
21 Aug
11:41 p.m.
----------------------------------------------------------------------------------------
Secretariat Impact Assessment: prop-154-v001
----------------------------------------------------------------------------------------
APNIC notes that the proposed default IPv4 delegation size for
any new IXP will be a /26, and the IXP can request more based on
the number of peers connected at that IX facility. Current large
IXP account holders can request a contiguous /22 IPv4 if 80% of
the current /23 IPv4 is used, and the existing /23 must be returned
to APNIC.
APNIC also notes that the proposal suggests APNIC check the routing
table to revoke any less than /24 IPv4 delegations announced in the
global routing table.
Questions/Comments:
------------------------------
- Can an existing account holder request more IP addresses if they
have already received their final /23 IPv4 under the current IPv4
policy and want to start an IXP?
- There is an assumption with this proposal that IXP-type account holders
only have IXP assignments. How do the authors propose APNIC applies this
to account holders who have both regular allocations and IXP assignments?
- The current minimum transfer size for IPv4 addresses is /24. If an IXP
receives a /25 or /26, they cannot transfer it even after using it for 5 years,
unlike IXPs who receive /24 or larger assignments. Is this the author's
intention, or should there be a transfer restriction on all IXP assignments
made under this proposal?
- According to the proposal, a national IXP in an economy with fewer than
60 account holders cannot have more than /27 IPv4 assignment. The proposed
default size, however, is a /26. Is this the author's intention, or a typo?
Implementation:
----------------------
This proposal may require changes to business rules and systems. If this
proposal reaches consensus, implementation may be completed within six
months.
Regards,
Sunny
Secretariat Impact Assessment: prop-154-v001
----------------------------------------------------------------------------------------
APNIC notes that the proposed default IPv4 delegation size for
any new IXP will be a /26, and the IXP can request more based on
the number of peers connected at that IX facility. Current large
IXP account holders can request a contiguous /22 IPv4 if 80% of
the current /23 IPv4 is used, and the existing /23 must be returned
to APNIC.
APNIC also notes that the proposal suggests APNIC check the routing
table to revoke any less than /24 IPv4 delegations announced in the
global routing table.
Questions/Comments:
------------------------------
- Can an existing account holder request more IP addresses if they
have already received their final /23 IPv4 under the current IPv4
policy and want to start an IXP?
- There is an assumption with this proposal that IXP-type account holders
only have IXP assignments. How do the authors propose APNIC applies this
to account holders who have both regular allocations and IXP assignments?
- The current minimum transfer size for IPv4 addresses is /24. If an IXP
receives a /25 or /26, they cannot transfer it even after using it for 5 years,
unlike IXPs who receive /24 or larger assignments. Is this the author's
intention, or should there be a transfer restriction on all IXP assignments
made under this proposal?
- According to the proposal, a national IXP in an economy with fewer than
60 account holders cannot have more than /27 IPv4 assignment. The proposed
default size, however, is a /26. Is this the author's intention, or a typo?
Implementation:
----------------------
This proposal may require changes to business rules and systems. If this
proposal reaches consensus, implementation may be completed within six
months.
Regards,
Sunny
On 8/08/2023 2:11 pm, Shaila Sharmin
wrote:
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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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-leave@lists.apnic.net
-- _______________________________________________________________________ Srinivas (Sunny) Chendi (he/him) Senior Advisor - Policy and Community Development Asia Pacific Network Information Centre (APNIC) | Tel: +61 7 3858 3100 PO Box 3646 South Brisbane, QLD 4101 Australia | Fax: +61 7 3858 3199 6 Cordelia Street, South Brisbane, QLD | http://www.apnic.net _______________________________________________________________________ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
28 Aug
9:44 p.m.
Good morning,
Some concerns from IAA:
This could lead to an incentive for people setting up exchanges merely for the purposes of obtaining IP addresses. The rules should be such that addresses must not be routed publicly, and should be returned to APNIC should the exchange cease operation or effectively become defunct (<2 members) .
It also doesn’t assist organisations that operate multiple exchanges and may be expanding into new location, where the new exchange would have a high probability of success.
The policy should apply on a “per functioning exchange” basis, as a special class for address space for exchanges that are also reserved so that APNIC can claim the allocation back should the exchange fold, and allow future expansion when an existing exchange expands to service a wider geography.
Policy Officer
Internet Association of Australia Ltd
Suite 1.05, 150 Pacific Highway • North Sydney, NSW 2060
02 9037 6404
1300
653 132
sophia.joo@internet.asn.au
www.internet.asn.au
From: Shaila Sharmin <shaila.sharmin.ovi@gmail.com>
Sent: Tuesday, August 8, 2023 2:12 PM
To: sig-policy <sig-policy@lists.apnic.net>
Subject: [sig-policy] prop-154-v001: Resizing of IPv4 assignment for the IXPs
CAUTION: This email originated from outside IAA. Do not click links or open attachments unless you recognise the sender and know the content is safe. If you have any concerns please contact your manager.
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-154
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-154-v001: Resizing of IPv4 assignment for the IXPs
----------------------------------------------------------------
Proposer: Simon Sohel Baroi (sbaroi@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 the places the resources have been under-utilised and new
IXPs are wasting a large
amount of valuable IPv4 spaces. 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 number
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 /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 /24 when they can justify having
more than 100 peers on
the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60
registered APNIC members
or resource holders (from other RIRs or legacy space holders) then there
is no justification to
have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing
assignments. The existing assignment must be returned by the IXP within 3
months of the new assignment.
Any resources less than /24 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.
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.
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.
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/
1 Sep
4:44 a.m.
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 30th Aug to discuss these proposals.
Many Negative opinions were expressed about this proposal.
(comment details) - Renumbering is very labor intensive. Some users may stop planning to connect to the /26 IXP because they do not want to renumber in the future.
- Who will manage the reverse DNS for longer than /24 prefixes ? If it is managed by APNIC or NIR, it would require a major modification such as system change.
- It is hard to imagine that so many new IXPs will be established before IPv4 addresses run out, So it is assumed that the IPv4 that can be saved will be limited. The disadvantages may be greater when compared to the effort and cost for APNICs, IXPs, and IXP users to implement this proposal.
Regards,
Satoru Tsurumaki / JPOPF Steering Team
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 Anupam APNIC Policy SIG Chairs
prop-154-v001: Resizing of IPv4 assignment for the IXPs
Proposer: Simon Sohel Baroi (sbaroi@gmail.com) Aftab Siddiqui
- 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 the places the resources have been under-utilised and new IXPs are wasting a large amount of valuable IPv4 spaces. 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 number 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 | +-------------------+-------+------------+-------+---------------------------+
- Objective of policy change
The objective of this proposal is to modify the default size of IPv4 assignments for IXPs from /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.
- 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]
- 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 /24 when they can justify having more than 100 peers on the IXP fabric (peering LAN) in the next 12 months.
If it is a national IXP and the said economy doesn’t have more than 60 registered APNIC members or resource holders (from other RIRs or legacy space holders) then there is no justification to have more than /27 assignments.
An IXP which received an assignment less than /24 can request upto /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 80% of existing assignments. The existing assignment must be returned by the IXP within 3 months of the new assignment.
Any resources less than /24 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.
- 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.
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).
- 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.
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-leave@lists.apnic.net
1 Sep
8:13 a.m.
Hello,
answering with my hat as one of the co-authors of the corresponding RIPE policy on, also with my hat as "working at an IXP":
On 1. Sep 2023, at 06:44, Satoru Tsurumaki stsuruma@gmail.com wrote:
(comment details)
- Renumbering is very labor intensive. Some users may stop planning to connect to the /26 IXP because they do not want to renumber in the future.
yes. But it is manageable. We did it several times for *large* IXPs. And before anyone suggests netmask change instead of renumbering: Our experience shows that netmask change is way more painful than renumbering.
- It is hard to imagine that so many new IXPs will be established before IPv4 addresses run out, So it is assumed that the IPv4 that can be saved will be limited.
we have seen many *very small" IXPs popping up who never will need a /24. Have a look at this study my colleague Matthias did: https://github.com/mwichtlh/address-policy-wg
Having said that - I am all in favor of this policy change
best regards Wolfgang
--
Wolfgang Tremmel
Phone +49 69 1730902 0 | wolfgang.tremmel@de-cix.net
Executive Directors: Ivaylo Ivanov and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135
DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net
Activity Summary
- 95 days inactive
- 95 days old
- sig-policy@lists.apnic.net
- 13 participants
- 23 comments