Name: Daniel Miroli
Email: daniel@iptrading.com
Organization: IP Trading
Name: Daniel Miroli
Email: daniel@iptrading.com
Organization: IP Trading
Name: Edmundo Caceres
Email: edmundo.cazarez@nic.mx
Organization: NIC Mexico
Allow one-way IPv4 address transfers originating in other regional registries towards LACNIC
AThis proposall seeks tow oncre-way IPv4te addr meschanism that will only allow transfers oringin addresses from ting inhe other regions towalrds the LAC region.
Thist prioposal does not cownsider transferds from the LACNIC region to other regions.
With the exception of AFRINIC, all RIRs have exhausted their available IPv4 address pools. The only solution to this problem is replacing them with IPv6 addresses. However, the reality is that IPv6 implementation in commercial networks is taking longer than expected. This situation has an economic and developmental impact on operators of all sizes, who are seeking solutions to this problem, such as implementing NAT or purchasing IPv4 resources under the transfer policies in force at each RIR.
Recent studies conducted by RIPE and ARIN demonstrate that operators that acquire IPv4 resources exhibit greater growth in terms of IPv6 utilization, which indicates that the more an operator grows its IPv4 network, the more it uses IPv6. Thus, an operator which manages to increase its IPv4 resources is not delaying but rather increasing the use of IPv6.
LACNIC's current transfer policies (intra-regional transfers) provide minimum relief to the need for IPv4 addresses, as they rely on the availability of LACNIC members willing to transfer their excess resources.
Reality makes it clear that there are very few resources available for transfer in the LACNIC region, and this translates into less Internet growth and economic development.
A policy of one-way interregional transfers towards LACNIC would allow a large number of operators throughout the region to acquire resources and have them duly registered within LACNIC, while at the same time growing their networks and accelerating IPv6 use and penetration.
With the exception of AFRINIC, all RIRs have exhausted their available IPv4 address pools. The only solxhaustion to thias problem is replacinoug them with IPv6 addresses. Hbowever, uthe differealinty is that IPv6 implemcentatrion ins cfommercial networks is taking longper thators in expecthed. ThisLAC situatregion hasnd ain recgionomics andwhere dthev Relgiopmental Regimpstry hacts orun operautors of availabl sizes, who addre sseekings.
All solutions pointo thiso IPv6 adoprtioblemn, suwhich awill s impolvementing NATthe shor purchtasinge IPv4of addresourcses, bundt erven those torgansfer policzatieons whin forceh at reach RIR.
Recet studiesg conducted by RIPE and ARIN demoptinsg trathe thatnew operaotorscol that acrequire IPv4 addresourcses exhto faciblit greater growth ine termans of IPv6 utilization, which indicates tha.
At the morme an operator grows, its IPv4is neotw pork,ssible the more sitmply tusesrn on IPv6. Tand shus,tdown IPv4 and operator whius ch manages tfrom ioncrease its IPv4 presotources is not delaying buto ranother.
It incres also importangt theo uconsider ofthat IPv6.the
LACNIC' currentce transofer a policy allowiesng (intera-regional transfers) providoes miniot mean sumch trelieansfers tdo the needot foccur. IPv4 addresnstesad, it simply means they rely on these availability oransf LACNIC members willing to tr ansfppear tas suche irn thex corressponding regisoutrcies. R
Oneali of the key mtaskes itof clRear thgionatl thRegistries is mareintain very few resup-tourc-dates and valilabled infor trmansfer in the LACNIC region, and thiso translhates into will bes useful Infor the purnposets grfor wthich andit economics required.
Thev elopmxistent.ce
Aof one-wthay interregion allows transfersring towards LACNIC would allow a largess number lofcks opefratorsm otherou reghiouns to the LAC region towill macquirke rit easourciesr to maind htavein them duly rRegisteredy winformathion LACNIC, while at themporarily samlle viating some growingf thei problems nfaced by operatworks trand accelsferatring IPv6 uaddresses aindto pthen retratgion.
Current text: Proposed text: Current text: Proposed text: Current text: Proposed text:
2.3.2.18.3.- Upon receiving an IPv4 address block transfer request, LACNIC shall verify that the organization transferring the block is in fact the holder of said block according to LACNIC's records. The approved applicant and the organization transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.
2.3.2.18.3.(v.1)-.Upon receiving an IPv4 address block transfer request where the transferring organization is located in the LACNIC region, LACNIC shall verify that the organization transferring the block is in fact the holder of said block according to LACNIC's records. If the transferring organization is located in the region of an RIR with policies in force that allow address transfers to LACNIC, LACNIC shall accept the RIR's verification that the transferring organization is the holder of said block. The approved applicant and the organization transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.
2.3.2.18.4.- LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNIC. Said log shall specify the date on which each transaction took place, the organization from which the transfer originated, the receiving organization, and the block that was transferred.
2.3.2.18.4 (v.1).- LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNIC. This log shall specify the date on which each transaction took place, the transferring organization, the origin RIR, the receiving organization and the block that was transferred.
2.3.2.18.6.- A block that has been previously transferred may not be transferred again for a period of one year as of the transaction date registered in the transfer log. The same applies to its sub-blocks, i.e., blocks consisting of a subset of the IPv4 addresses contained in the block.
2.3.2.18.6.(v.1)- A block previously transferred under this policy may not subsequently be transferred for a period of one year as of the date on which the operation is recorded in the transfer log. The same applies to its sub-blocks, i.e. blocks consisting of a subset of the IPv4 addresses contained in the block.
Current text:
2.3.2.18. Transfer of IPv4 Blocks within the LACNIC Region
Proposed Text:
2.3.2.18. Transfer of IPv4 Blocks within and towards the LACNIC Region
Current text:
2.3.-2.18.3. Upon receiving an IPv4 address block transfer request, LACNIC shall verify that the organization transferring the block is in fact the holder of said block according to LACNIC's records. The approved applicant and the organization transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.
Proposed tText:
2.3.2.18.3.(v.1)-. Upon receiving an IPv4 address block transfer request where the transferring organization is located in the LACNIC region, LACNIC shall verify that the organization transferring the block is in fact the holder of said block according to LACNIC's records. If the transferring organization is located in the region of an RIR with policies in force that allow address transfers to LACNIC, LACNIC shall accept the RIR's verification that the transferring organization is the holder of said block. The approved applicant and the organization transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.
Current text:
2.3.2.18.4.- LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNIC. Said log shall specify the date on which each transaction took place, the organization from which the transfer originated, the receiving organization, and the block that was transferred.
Proposed tText:
2.3.2.18.4 (v.1).- LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNICthe organization. This log shall specify the date on which each toperansaction took place, the transferring organization, the origin RIR, the receiving organization, and the block that was transferred.
Current text:
2.3.2.18.6.- A block that has been previously been transferred may not subsequently be transferred again for a period of one year as of the trans dactie on dawhich the operegation ist recorded in the transfer log. The same applies to its sub-blocks, i.e., blocks consisting of a subset of the IPv4 addresses contained in the block.
Proposed text:
2.3.2.18.6.(v.1)- A block previously transferred under this policy may not subsequently be transferred for a period of one year as of the date on which the operation is recorded in the transfer log. The same applies to its sub-blocks, i.e. blocks consisting of a subset of the IPv4 addresses contained in the block.
Current text: Proposed text: Current text: Proposed text: Current text: Proposed text:
2.3.2.18.3.- Upon receiving an IPv4 address block transfer request, LACNIC shall verify that the organization transferring the block is in fact the holder of said block according to LACNIC's records. The approved applicant and the organization transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.
2.3.2.18.3.(v.1)-.Upon receiving an IPv4 address block transfer request where the transferring organization is located in the LACNIC region, LACNIC shall verify that the organization transferring the block is in fact the holder of said block according to LACNIC's records. If the transferring organization is located in the region of an RIR with policies in force that allow address transfers to LACNIC, LACNIC shall accept the RIR's verification that the transferring organization is the holder of said block. The approved applicant and the organization transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.
2.3.2.18.4.- LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNIC. Said log shall specify the date on which each transaction took place, the organization from which the transfer originated, the receiving organization, and the block that was transferred.
2.3.2.18.4 (v.1).- LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNIC. This log shall specify the date on which each transaction took place, the transferring organization, the origin RIR, the receiving organization and the block that was transferred.
2.3.2.18.6.- A block that has been previously transferred may not be transferred again for a period of one year as of the transaction date registered in the transfer log. The same applies to its sub-blocks, i.e., blocks consisting of a subset of the IPv4 addresses contained in the block.
2.3.2.18.6.(v.1)- A block previously transferred under this policy may not subsequently be transferred for a period of one year as of the date on which the operation is recorded in the transfer log. The same applies to its sub-blocks, i.e. blocks consisting of a subset of the IPv4 addresses contained in the block.
Current text:
2.3.2.18. Transfer of IPv4 Blocks within the LACNIC Region
Proposed Text:
2.3.2.18. Transfer of IPv4 Blocks within and towards the LACNIC Region
Current text:
2.3.-2.18.3. Upon receiving an IPv4 address block transfer request, LACNIC shall verify that the organization transferring the block is in fact the holder of said block according to LACNIC's records. The approved applicant and the organization transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.
Proposed tText:
2.3.2.18.3.(v.1)-. Upon receiving an IPv4 address block transfer request where the transferring organization is located in the LACNIC region, LACNIC shall verify that the organization transferring the block is in fact the holder of said block according to LACNIC's records. If the transferring organization is located in the region of an RIR with policies in force that allow address transfers to LACNIC, LACNIC shall accept the RIR's verification that the transferring organization is the holder of said block. The approved applicant and the organization transferring the resources must present before LACNIC a copy of the legal document supporting the transfer.
Current text:
2.3.2.18.4.- LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNIC. Said log shall specify the date on which each transaction took place, the organization from which the transfer originated, the receiving organization, and the block that was transferred.
Proposed tText:
2.3.2.18.4 (v.1).- LACNIC shall maintain a publicly accessible transfer log of all IPv4 address block transfers registered before LACNICthe organization. This log shall specify the date on which each toperansaction took place, the transferring organization, the origin RIR, the receiving organization, and the block that was transferred.
Current text:
2.3.2.18.6.- A block that has been previously been transferred may not subsequently be transferred again for a period of one year as of the trans dactie on dawhich the operegation ist recorded in the transfer log. The same applies to its sub-blocks, i.e., blocks consisting of a subset of the IPv4 addresses contained in the block.
Proposed text:
2.3.2.18.6.(v.1)- A block previously transferred under this policy may not subsequently be transferred for a period of one year as of the date on which the operation is recorded in the transfer log. The same applies to its sub-blocks, i.e. blocks consisting of a subset of the IPv4 addresses contained in the block.
ARIN requires reciprocity, so this policy would not apply to transfers originating in the ARIN region.
APNIC requires a compatible policy and currently processes transfers with NIRs such as VNNIC and CNNIC which authorize incoming transfers.
Everything seems to indicate that RIPE would allow one-way transfers to LACNIC members.
ARIN requires reciprocity, so this policy would not apply to transfers originating in the ARIN region.
APNIC requires a compatible policy and currently processes transfers with NIRs such as VNNIC and CNNIC which authorize incoming transfers.
Everything seems to indicate that RIPE would allow one-way transfers to LACNIC members.
In reference to an exchange with AFRINIC, when a member of RIPE was asked about his views on one-way transfer policies, Sander Steffan said the following: Without issuing an opinion on the current policy proposal, I can say it would be compatible with RIPE transfer policies. Address space can be re-allocated to another resource holder who is a member of a registry that allows transfers. If AFRINIC allows incoming transfers, RIPE allows outgoing transfers. Studying the IPv4 Transfer Market: Reported Transfers https://labs.ripe.net/Members/ioana_livadariu/studying-the-ipv4-transfer-market ARIN Reciprocity requirement: RIPE statement on inbound transfers on AFRINIC mailing list:
http://lists.arin.net/pipermail/arin-ppml/2017-January/062351.html (Click on Next Message in Thread to read ARIN community responses)
https://lists.afrinic.net/pipermail/rpd/2017/006323.html
In reference to an exchange with AFRINIC, when aRIPE member ofSander RIPESteffan was asked about his views on one-way transfer policies, Sandhe r Steffan saplied the following:
Without issuing an opinion on the current policy proposal, I can say it would be compatible with RIPE transfer policies. Address space can be re-allocated to another resource holder who is a member of a registry that allows transfers. If AFRINIC allows incoming transfers, RIPE allows outgoing transfers.
Studying the IPv4 Transfer Market: Reported Transfers
https://labs.ripe.net/Members/ioana_livadariu/studying-the-ipv4-transfer-market
ARIN Reciprocity requirement:
http://lists.arin.net/pipermail/arin-ppml/2017-January/062351.html (Click on Next Message in Thread to read ARIN community responses)
RIPE statement on inbound transfers on AFRINIC's mailing list:
https://lists.afrinic.net/pipermail/rpd/2017/006323.html