Nombre: Daniel Miroli
Email: daniel@iptrading.com
Organización: IP Trading
Nombre: Daniel Miroli
Email: daniel@iptrading.com
Organización: IP Trading
Nombre: Edmundo Caceres
Email: edmundo.cazarez@nic.mx
Organización: NIC Mexico
Permitir la Transferencias de direcciones de IPv4 originadas en otros registros regionales en un sentido hacia LACNIC
PEsta propuesta busca crear un mecanismo que unicamente permirta la Ttransferencias de direcciones de IPv4otras oriegiones hadcia las región oLAC.
La transferencia de direcciones desde la regisón LAC hacia otroas regionales no está contemplada uen la presentide pro hpuestacia LACNIC.
Todos los RIR con la excepción de AFRINIC han agotado la disponibilidad de IPv4, la única solución a este problema es su remplazo por IPv6, pero la realidad es que su implementación en las redes comerciales es más lento de lo esperado, esta situación afecta en términos económicos y de desarrollo a muchos operadores de toda envergadura, los cuales buscan soluciones al problema como la implementación de NAT o la compra de IPv4 de acuerdo a las políticas de transferencias de cada RIR
En estudios realizados recientemente en RIPE y ARIN, se demuestra que operadores que adquieren IPv4 tienen un mayor crecimiento en la utilización de IPv6, lo cual pone en evidencia que más crece un operador su red de IPv4 mas utiliza IPv6, por lo cual un operador que logra aumentar su número de IPv4 no está retardando el uso de IPv6 sino aumentándolo.
Las políticas actuales de transferencia de LACNIC (intra-regionales) alivian en manera mínima la necesidad de IPv4, la oferta se basa en la disponibilidad de los miembros de LACNIC que quieran ofrecer a ser transferidos los recursos que tienen en exceso.
La realidad hace evidente la poca cantidad de recursos disponibles para transferencias en LACNIC, lo cual se traduce en un menor crecimiento de redes y económico del Internet.
Una política de transferencias inter-regionales en sentido “unidireccional hacia LACNIC”, de daría la oportunidad a una gran cantidad de operadores de la región de poder adquirir recursos y tenerlos registrados debidamente dentro de LACNIC al tiempo que crecerían sus redes y acelerarían la penetración y el uso de IPv6.
Todos los RIR con lLa excteprminación del AFRINIC hespan agciota do lae dispreccionibilidad des IPv4, lha únictraido disoluctión atos estce pnarioblema es sua remplazos por IPv6, peradores lade realidad es qude sula implrementacgión LAC y den las redes comercgialones es másn ledonto de elo Regispetrado, Resta situacgióonal afectya eno térmienose direccionómicoes y de deisarrpolniblo a muchoes operadores dea toda esignvergadura, los cuales busc.
Lan solucioónes al problema cque tomdos la implemeuntación de NAT os la cadompración de IPv4 de6, acque rdeso alverá la es políticasez de transfedirencciaones, dpero cada RIRún las
Eestudios regalnizadciones rqueci están temerabajantedo en RIPE y ARIN,adoptar sel demnuestvo praotocolo requieren optenera dispornibles que adquierecciones IPv4 tienen qune mfayor crecimliento en ltal utilransización.
Por del IPv6,momento lno cuales ponsible hacer un evidencendiado qude másIPv6 crecey un oaperagador su red de IPv4 mpasra utilcambizar IPv6,de pror lto cuaol un oper.
Hadory que lcognsiderar, taumebiéntar, squ número de IPv4la no existá retardando el usocia de IPv6 sino aumentándolo.a
Ls políticas actquales dpermita la transferencia de LACNICdirecciones (ientra-e regionales) no alivmplican quen mestas neo ocurra mín: sima pla emente implicesidad dque IPv4,no laparecen comofer ta sle basa en laos dregistros correspondibilidentes.
Unad de loas miembtaroeas de LACNIC qfue quieran ofrecer da smer ntranlesferi dose los rRecugistrsos quRe tgieonalens ens exceso.ta
L re actualidzados hacey evidentque la pinfocrma cantidadón dque recursos dispontibles para transferencia s ena LACNICválida, de lforma cquale sea útil paraduc los fines en qune msenor crecimquiento dera.
La redexis y teconómcicoa del Internet.una política
Udque permita la transferencia de bloques intder- diregccionales den sden otidoras “unidireccgionales hacia la región LACNIC”, de dfacilitaríaá el ma oporntuenidamiento de la uina gforman cantidadón del opRegistradores, dea la región dvez podquer adqulirviará temporalmecnte algursnos yde tenerlos problegimastra de los dopebidramente dorentros dque LACNIC hagaln tirasnfempo que crenceríian sus rde direcciones y haceleriarían la pdenetración yo del usola dre IPv6gión.
Texto Actual, 2.3.2.18.3.- Ante una solicitud de transferencia de un bloque IPv4, LACNIC verificará que la entidad fuente es el titular de dicho bloque según conste en los registros de LACNIC. El Texto Propuesto, 2.3.2.18.3.(v.1) -.Ante una solicitud de transferencia de un bloque de direcciones ipv4 cuya fuente esté en la región de LACNIC, LACNIC verificará que la organización que transfiere el bloque es de hecho el titular de dicho bloque de acuerdo con los registros de LACNIC. Si la fuente de la solicitud de transferencia está dentro de una región cuyas políticas RIR permiten la transferencia de direcciones a LACNIC, LACNIC aceptará la verificación del RIR de la fuente de que la fuente es el titular de dicho bloque. El solicitante aprobado y la organización que transfiere los recursos deben presentar ante LACNIC una copia del documento legal que respalda la transferencia. Texto Actual, 2.3.2.18.4.- LACNIC mantendrá una bitácora de transferencias, accesible públicamente, Texto Propuesto, 2.3.2.18.4 (v.1).- LACNIC mantendrá una bitácora de transferencia accesible públicamente de todas las transferencias de bloques de direcciones IPv4 registradas ante LACNIC. Dicho registro especificará la fecha en que tuvo lugar cada transacción, la organización de la que se originó la transferencia, el RIR de origen, la organización receptora y el bloque que se transfirió. Texto Actual, 2.3.2.18.6.- Un bloque previamente transferido no podrá ser subsecuentemente Texto propuesto 2.3.2.18.6.(v.1)- Un bloque previamente transferido bajo esta politica no podrá ser subsecuentemente
solicitante aprobado y la entidad que transferiría deberán presentar a LACNIC una copia del documento legal que respalde la transferencia.
de todas las transferencias de bloques IPv4 que se registren ante él. En dicha bitácora se
registrará la fecha de la operación, la entidad fuente de la transferencia, la entidad destino
y el bloque transferido.
transferido durante un periodo de un año, a partir de la fecha de operación registrada en
la bitácora de transferencias. Lo mismo aplica para sus sub-bloques, es decir, bloques
que agrupen un subconjunto de las direcciones IPv4 que contiene el bloque
transferido durante un periodo de un año, a partir de la fecha de operación registrada en
la bitácora de transferencias. Lo mismo aplica para sus sub-bloques, es decir, bloques
que agrupen un subconjunto de las direcciones IPv4 que contiene el bloque.
Texto Actual,:
2.3.2.18. Transferencias de bloques IPv4 dentro de la región LACNIC
Texto Propuesto:
2.3.2.18. Transferencias de bloques IPv4 dentro y hacia la región LACNIC
Texto Actual
2.3.-2.18.3. Ante una solicitud de transferencia de un bloque IPv4, LACNIC verificará que la entidad fuente es el titular de dicho bloque según conste en los registros de LACNIC. El solicitante aprobado y la entidad que transferiría deberán presentar a LACNIC una copia del documento legal que respalde la transferencia.
Texto Propuesto,
2.3.2.18.3.(v.1) -.Ante una solicitud de transferencia de un bloque de direcciones ipv4 cuya fuente esté en la región de LACNIC, LACNIC verificará que la organización que transfiere el bloque es de hecho el titular de dicho bloque de acuerdo con los registros de LACNIC. Si la fuente de la solicitud de transferencia está dentro de una región cuyas políticas RIR permiten la transferencia de direcciones a LACNIC, LACNIC aceptará la verificación del RIR de la fuente de que la fuente es el titular de dicho bloque. El solicitante aprobado y la organización que transfiere los recursos deben presentar ante LACNIC una copia del documento legal que respalda la transferencia.
Texto Actual,
2.3.2.18.4.- LACNIC mantendrá una bitácora de transferencias, accesible públicamente, de todas las transferencias de bloques IPv4 que se registren ante él. En dicha bitácora se registrará la fecha de la operación, la entidad fuente de la transferencia, la entidad destino y el bloque transferido.
Texto Propuesto,
2.3.2.18.4 (v.1).- LACNIC mantendrá una bitácora de transferencia accesible públicamente de todas las transferencias de bloques de direcciones IPv4 registradas ante LACNICél. Dicho registro especificará la fecha en que tuvo lugar cada toperansacción, la organización de la que se originó la transferencia, el RIR de origen, la organización receptora y el bloque que se transfirió.
Texto Actual,
2.3.2.18.6.- Un bloque previamente transferido no podrá ser subsecuentemente transferido durante un periodo de un año, a partir de la fecha de operación registrada en la bitácora de transferencias. Lo mismo aplica para sus sub-bloques, es decir, bloques que agrupen un subconjunto de las direcciones IPv4 que contiene el bloque.Texto propuesto
2.3.2.18.6.(v.1)- Un bloque previamente transferido bajo esta politica no podrá ser subsecuentemente transferido durante un periodo de un año, a partir de la fecha de operación registrada en la bitácora de transferencias. Lo mismo aplica para sus sub-bloques, es decir, bloques que agrupen un subconjunto de las direcciones IPv4 que contiene el bloque.
Texto Actual, 2.3.2.18.3.- Ante una solicitud de transferencia de un bloque IPv4, LACNIC verificará que la entidad fuente es el titular de dicho bloque según conste en los registros de LACNIC. El Texto Propuesto, 2.3.2.18.3.(v.1) -.Ante una solicitud de transferencia de un bloque de direcciones ipv4 cuya fuente esté en la región de LACNIC, LACNIC verificará que la organización que transfiere el bloque es de hecho el titular de dicho bloque de acuerdo con los registros de LACNIC. Si la fuente de la solicitud de transferencia está dentro de una región cuyas políticas RIR permiten la transferencia de direcciones a LACNIC, LACNIC aceptará la verificación del RIR de la fuente de que la fuente es el titular de dicho bloque. El solicitante aprobado y la organización que transfiere los recursos deben presentar ante LACNIC una copia del documento legal que respalda la transferencia. Texto Actual, 2.3.2.18.4.- LACNIC mantendrá una bitácora de transferencias, accesible públicamente, Texto Propuesto, 2.3.2.18.4 (v.1).- LACNIC mantendrá una bitácora de transferencia accesible públicamente de todas las transferencias de bloques de direcciones IPv4 registradas ante LACNIC. Dicho registro especificará la fecha en que tuvo lugar cada transacción, la organización de la que se originó la transferencia, el RIR de origen, la organización receptora y el bloque que se transfirió. Texto Actual, 2.3.2.18.6.- Un bloque previamente transferido no podrá ser subsecuentemente Texto propuesto 2.3.2.18.6.(v.1)- Un bloque previamente transferido bajo esta politica no podrá ser subsecuentemente
solicitante aprobado y la entidad que transferiría deberán presentar a LACNIC una copia del documento legal que respalde la transferencia.
de todas las transferencias de bloques IPv4 que se registren ante él. En dicha bitácora se
registrará la fecha de la operación, la entidad fuente de la transferencia, la entidad destino
y el bloque transferido.
transferido durante un periodo de un año, a partir de la fecha de operación registrada en
la bitácora de transferencias. Lo mismo aplica para sus sub-bloques, es decir, bloques
que agrupen un subconjunto de las direcciones IPv4 que contiene el bloque
transferido durante un periodo de un año, a partir de la fecha de operación registrada en
la bitácora de transferencias. Lo mismo aplica para sus sub-bloques, es decir, bloques
que agrupen un subconjunto de las direcciones IPv4 que contiene el bloque.
Texto Actual,:
2.3.2.18. Transferencias de bloques IPv4 dentro de la región LACNIC
Texto Propuesto:
2.3.2.18. Transferencias de bloques IPv4 dentro y hacia la región LACNIC
Texto Actual
2.3.-2.18.3. Ante una solicitud de transferencia de un bloque IPv4, LACNIC verificará que la entidad fuente es el titular de dicho bloque según conste en los registros de LACNIC. El solicitante aprobado y la entidad que transferiría deberán presentar a LACNIC una copia del documento legal que respalde la transferencia.
Texto Propuesto,
2.3.2.18.3.(v.1) -.Ante una solicitud de transferencia de un bloque de direcciones ipv4 cuya fuente esté en la región de LACNIC, LACNIC verificará que la organización que transfiere el bloque es de hecho el titular de dicho bloque de acuerdo con los registros de LACNIC. Si la fuente de la solicitud de transferencia está dentro de una región cuyas políticas RIR permiten la transferencia de direcciones a LACNIC, LACNIC aceptará la verificación del RIR de la fuente de que la fuente es el titular de dicho bloque. El solicitante aprobado y la organización que transfiere los recursos deben presentar ante LACNIC una copia del documento legal que respalda la transferencia.
Texto Actual,
2.3.2.18.4.- LACNIC mantendrá una bitácora de transferencias, accesible públicamente, de todas las transferencias de bloques IPv4 que se registren ante él. En dicha bitácora se registrará la fecha de la operación, la entidad fuente de la transferencia, la entidad destino y el bloque transferido.
Texto Propuesto,
2.3.2.18.4 (v.1).- LACNIC mantendrá una bitácora de transferencia accesible públicamente de todas las transferencias de bloques de direcciones IPv4 registradas ante LACNICél. Dicho registro especificará la fecha en que tuvo lugar cada toperansacción, la organización de la que se originó la transferencia, el RIR de origen, la organización receptora y el bloque que se transfirió.
Texto Actual,
2.3.2.18.6.- Un bloque previamente transferido no podrá ser subsecuentemente transferido durante un periodo de un año, a partir de la fecha de operación registrada en la bitácora de transferencias. Lo mismo aplica para sus sub-bloques, es decir, bloques que agrupen un subconjunto de las direcciones IPv4 que contiene el bloque.Texto propuesto
2.3.2.18.6.(v.1)- Un bloque previamente transferido bajo esta politica no podrá ser subsecuentemente transferido durante un periodo de un año, a partir de la fecha de operación registrada en la bitácora de transferencias. Lo mismo aplica para sus sub-bloques, es decir, bloques que agrupen un subconjunto de las direcciones IPv4 que contiene el bloque.
ARIN requiere reciprocidad, de manera que esta política no aplicaría a originadores de ARIN
APNIC requiere una política compatible y APNIC al momento procesa transferencias con NIRs como VNNIC y CNNIC los cuales autorizan trasferencias entrantes, todo indicaría que RIPE permitiría transferencias unidireccionales a los miembros de LACNIC
ARIN requiere reciprocidad, de manera que esta política no aplicaría a originadores de ARIN
APNIC requiere una política compatible y APNIC al momento procesa transferencias con NIRs como VNNIC y CNNIC los cuales autorizan trasferencias entrantes, todo indicaría que RIPE permitiría transferencias unidireccionales a los miembros de LACNIC
Cuando en referencia a un intercambio con AFRINIC se le pregunto a un miembro de RIPE su opinión sobre las políticas de transferencia en un solo sentido, Sander Steffan dijo lo siguiente: Estudiando el Mercado de Transnsferencias de IPv4,: Transferencias Reportadas Requerimientos de reciprocidad de ARIN Declaraciones de RIPE sobre transferencias entrantes en la lista de AFRINIC
Sin emitir una opinión en la actual propuesta de política, puedo decir que sería compatible con las políticas de transferencia de RIPE, espacios de direcciones pueden ser re-alocadas a otro poseedor de recursos que sea miembro de un registro que permita transferencias, Si AFRINIC permite trasferencias hacia adentro en consecuencia RIPE permite transferencias hacia afuera.
https://labs.ripe.net/Members/ioana_livadariu/studying-the-ipv4-transfer-market
http://lists.arin.net/pipermail/arin-ppml/2017-January/062351.html
https://lists.afrinic.net/pipermail/rpd/2017/006323.html
Cuando en referencia a un intercambio con AFRINIC se le pregunto a un miembro de RIPE su opinión sobre las políticas de transferencia en un solo sentido, Sander Steffan dijo lo siguiente:
Sin emitir una opinión en la actual propuesta de política, puedo decir que sería compatible con las políticas de transferencia de RIPE, espacios de direcciones pueden ser re-alocadas a otro poseedor de recursos que sea miembro de un registro que permita transferencias, Si AFRINIC permite trasferencias hacia adentro en consecuencia RIPE permite transferencias hacia afuera.
Estudiando el Mercado de Transnsferencias de IPv4,: Transferencias Reportadas
https://labs.ripe.net/Members/ioana_livadariu/studying-the-ipv4-transfer-market
Requerimientos de reciprocidad de ARIN
http://lists.arin.net/pipermail/arin-ppml/2017-January/062351.html
Declaraciones de RIPE sobre transferencias entrantes en la lista de AFRINIC
https://lists.afrinic.net/pipermail/rpd/2017/006323.html