[LACNIC/Politicas] LAC-2019-10: Eliminación de obligación de devolver direcciones
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Wed Mar 18 06:30:02 GMT+3 2020
Hola Edmundo,
Tanto los ISP existentes, como los nuevos entrantes (y con mayor motivo estos que estan haciendo la inversión ahora y no tienen "excusas" o razones técnicas de no poder ir a IPv6 porque a o x) deben aprender que:
- No hay IPv4.
- Si quieren "mas" IPv4, existen un mercado para pagar por el uso de más direcciones.
- Si son nuevos entrantes, deben ir directamente a IPv6-only e IPv4aaS, entre otras cosas porque sería absurdo para ellos hacer una inversión basada en lo que se hacia hace 10 años y no lo que se hace ahora y en los próximos años. Es una consideración no solo técnica, sino también económica para ellos.
- Si son nuevos entrantes, posiblemente tengan pocos clientes inicialmente, y muchos menos clientes que requieras IPv4 público. Si los clientes no requiren IPv4 público, utilizando 464XLAT te puedo decir cuales son las cuentas de cuantos clientes (aproximadamente) puede atender un ISP con 1.024 direcciones (lo explico abajo porque es un poco largo).
- Si siguen "anclados en el pasado", la comunidad no tiene porque facilitarles el camino dejandoles que obtengan un /22 de LACNIC y además se queden con el /22 (o el bloque que sea) que tengan de su proveedor, entre otras cosas porque eso sería ir en *CONTRA* de la decisión de la comunidad de entregar un máximo de /22.
Creo que si la comunidad considera que en lugar de entregar un /22 y que haya un reparto mas equitativo para nuevos entrantes, es mejor que entreguemos lo que se ajuste a la necesidad de cada uno, y se agote antes el stock final de un RIR, entonces, lo correcto es cambiar todo lo relacionado con el reparto de la última fase en el manual.
** Estas son cuentas de casos reales de operadores, de cuantos clientes de pueden atender con 464XLAT y 1.024 direcciones.
464XLAT asigna puertos de forma dinámica en el NAT64, con lo cual no hay que pre-configurar cuantos puertos por usuario y ello permite maximizar el uso de las IPv4 públicas.
Un usuario medio utiliza 300 puertos (de una IP pública). Al usar 464XLAT, el número de usuarios dentro de la red, que en IPv4 está detrás del NAT46, no dispara el número de puertos. Vamos a suponer que sean el cuadruple 1.200 puertos.
Aproximadamente el 80% del tráfico (hace 2 años era el 75%, en muchos casos se esta llegando hasta el 90-95%) es IPv6. Luego de los 1.200 puertos solo contamos el 20%, que son 240 puertos.
A groso modo, si asignamos al NAT64 1.000 direcciones IPv4 (suponiendo que el operador necesite 24 direcciones IPv4 públicas para BGP e infraestructura, yo lo he hecho con mucho menos - porque el 99% de la infraestructura puede ser IPv6-only o usar IPv4 privadas para gestión), y que usemos de cada dirección IPv4 asignada al NAT64 solo 64.511 puertos (65.536-1.024), aún a sabiendas que se pueden usar todos:
1.000 x 64.511 / 240 = 268.795 usuarios.
Imáginemos que me equivoco en el 50%, es decir que se usan el doble de puertos (insisto en que me baso en datos reales y no de uno sino de varios casos). Aún pueden atender 134.397 usuarios, que es mas que lo que pueden atender con un /15 entregando direcciones públicas a todos los usuarios.
Hay que tener en cuenta, que según progresa el despliegue de IPv6 el uso del NAT64, y por tanto de las direcciones IPv4 públicas decrece, así que aunque ellos sigan creciendo, el despliegue de IPv6 les acompaña.
Crees que hay muchos "nuevos entrantes" que partan de "0" que inicialmente tengan ese número de suscriptores, o incluso el 10% ?
Si son "mas grandes", por poner un par de ejemplos, tenían un /19, y asignaban una IP publica a cada usuario, como mucho tenían 8.190 usuarios, si tenían un /15, tenían como mucho 131.070 usuarios.
Creo además, que ISPs "nuevos entrantes" que tengan esos volúmenes, les sale a cuenta acudir al mercado de direcciones (si realmente las necesitan porque su infraestructura no admite IPv6-only), o bien muy probablemente proceden o están inmersos en fusiones y adquisiciones, y por tanto, las direcciones vienen de otros lados.
Te puedo comentar varios casos de ISPs en Africa, Asia, Europa, y Norte América, donde esto ha ocurrido: El pez grande se ha comido a los mas chicos y tienen excedentes de direcciones o los han tenido durante varios años. De hecho, desafortunadamente, eso les ha permitido "no desplegar IPv6".
Saludos,
Jordi
El 18/3/20 1:50, "Politicas en nombre de Edmundo Cázarez López" <politicas-bounces at lacnic.net en nombre de edmundo.cazarez at nic.mx> escribió:
Hola Fernando,
> Si el destinatario de los recursos recibe sus propios recursos, es muy razonable pensar, especialmente a largo plazo, que esos recursos previamente asignados al proveedor deben ser devueltos para que puedan asignarse a otros clientes en el futuro y que estos recursos puedan reutilizarse mejor con el tiempo, especialmente en tiempos de escasez de IPv4.
Esto no necesariamente es conveniente para los nuevos entrantes. Hay redes que son realmente mas grandes que las 1000 direcciones IP que se le asignan a los nuevos entrantes. Las opciones para rehacer una red en ese caso realmente no son muchas, y adoptarlas implica un impacto severo para los operadores en esa situación, ya que deben rehacer su red con menos direcciones que las que están utilizando.
> En algún momento no muy lejano, cuando el pool de IPv4 para nuevos participantes esté completamente agotado, este será uno de los mecanismos para que existan nuevas organizaciones, utilizando estas asignaciones de IPv4 de sus proveedores para mecanismos de transición, incluso de una manera menos óptima.
Supongo que los ISP seguirán operando brindando servicios a otros operadores e menor tamaño, pero también hay que considerar que conforme lso operadores adoptan IPv6, es posible que liberen direcciones IPv4.
> Además, una organización que obtiene sus propias asignaciones de estos montos generalmente siempre será mayor de lo que tiene con su proveedor y, por lo tanto, la remuneración en este caso es parte del negocio. Si alguien no está preparado para llevar a cabo un plan de remuneración en un caso como este, entonces no está preparado para convertirse en un Sistema Autónomo.
Conozco casos de operadores que no tienen asignaciones directas por parte de LACNIC o un NIR y tienen en uso un /19, o incluso mas. A ellos no les sirve un /22 que les asignemos y de forma realista no es factible renumerar su red solo por un /22. Y creo que tienen la suficiente experiencia para tener incluso mas de un ASN.
Saludos.
-- Edmundo.
-
-----Original Message-----
From: Politicas <politicas-bounces at lacnic.net> On Behalf Of Fernando Frediani
Sent: Tuesday, March 17, 2020 7:33 AM
To: politicas at lacnic.net
Subject: Re: [LACNIC/Politicas] LAC-2019-10: Eliminación de obligación de devolver direcciones
Sigo siendo contrario a esta propuesta.
Si el destinatario de los recursos recibe sus propios recursos, es muy razonable pensar, especialmente a largo plazo, que esos recursos previamente asignados al proveedor deben ser devueltos para que puedan asignarse a otros clientes en el futuro y que estos recursos puedan reutilizarse mejor con el tiempo, especialmente en tiempos de escasez de IPv4.
En algún momento no muy lejano, cuando el pool de IPv4 para nuevos participantes esté completamente agotado, este será uno de los mecanismos para que existan nuevas organizaciones, utilizando estas asignaciones de IPv4 de sus proveedores para mecanismos de transición, incluso de una manera menos óptima.
Además, una organización que obtiene sus propias asignaciones de estos montos generalmente siempre será mayor de lo que tiene con su proveedor y, por lo tanto, la remuneración en este caso es parte del negocio. Si alguien no está preparado para llevar a cabo un plan de remuneración en un caso como este, entonces no está preparado para convertirse en un Sistema Autónomo.
Si las organizaciones que se han convertido en sistemas autónomos y tienen sus propias asignaciones también se les permite mantener las de sus proveedores con el tiempo, habrá un uso menos eficiente de estos recursos.
La única excepción que creo que es justa es para aquellos que, después de que el pool de IPv4 está completamente agotado, no tienen ninguna asignación de IPv4 y están esperando en una lista de espera o una transferencia.
Fernando Frediani
On 17/03/2020 09:27, Tomas Lynch via Politicas wrote:
> Estimados miembros de la lista,
>
> Recordamos que la propuesta de política "LAC-2019-10: Eliminación de
> obligación de devolver direcciones" sigue en discusión. Durante esta
> semana, del 16 al 22 de Marzo nos dedicaremos a la discusión de la
> misma [1].
>
> Les pedimos que respondan a este correo, sin cambiar el subject, si
> están de acuerdo o no con la propuesta adjuntando una breve
> descripción que sustente su posición [2].
>
> Encontrarán la propuesta completa en
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpoli
> ticas.lacnic.net%2Fpoliticas%2Fdetail%2Fid%2FLAC-2019-10%2Flanguage%2F
> sp&data=02%7C01%7Cedmundo.cazarez%40nic.mx%7C6507bad3153b447b7cca0
> 8d7ca77e87a%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C6372004886805
> 35798&sdata=hPbdBDmqDFams3RxSnLWJZvGivoSCEEN4mu6FErTZWk%3D&res
> erved=0
>
> A continuación se muestra el texto original y el de la propuesta:
>
> *Texto Actual*
> 2.3.3.1.1. - Requisitos para un prefijo /24 a un /22
>
> Para calificar para la distribución de un prefijo /24 a un /22 el ISP
> solicitante deberá cumplir los siguientes requisitos
>
> 1. Demostrar el uso o la necesidad inmediata de al menos el 25% del
> prefijo solicitado.
>
> 2. Entregar un plan detallado de uso de 50% de uso del prefijo
> solicitado para un año.
>
> - Si previamente había un bloque asignado por un proveedor, y se desea
> mantener el mismo para evitar la renumeración, y hay acuerdo entre
> ambas partes, se podrá ceder[1] dicho bloque (con el cambio de
> titularidad en el whois, a través de LACNIC).
>
> - Si se ha justificado espacio adicional y es posible su distribución,
> el receptor podrá decidir si la cesión le es conveniente y recibe un
> bloque por el espacio adicional o prefiere un único bloque por el
> total y, por lo tanto, renumera. En caso de renumeración, el bloque
> previamente asignado deberá ser retornado en un plazo máximo de 12
> meses. Excepcionalmente, este plazo podrá ser extendido en 6 meses
> adicionales si se justifica que no ha habido tiempo para la
> consecución de los recursos que precisa y la renumeración
> correspondiente.
>
> - En caso de que el solicitante aun no cuente con un bloque IPv6
> asignado por LACNIC, solicitar al mismo tiempo un bloque IPv6
> cumpliendo con la política aplicable.
>
> 2.3.3.1.2. - Requisitos para un prefijo /21 o menor (bloque de 8 /24 o
> más)
>
> En caso de que el ISP solicitante requiera una distribución inicial de
> direcciones IPv4 a partir de un prefijo /21 deberá cumplir los
> siguientes requerimientos
>
> - Proveer información de las asignaciones realizadas por prefijos de
> longitudes /29 o menores (más de 8 direcciones IPv4) en el WHOIS de
> LACNIC
>
> - Proveer documentación justificando la distribución de espacio de
> direcciones inicial. (Llenado de la plantilla de solicitud de
> direcciones IPv4 para ISP). Se deberá incluir información detallada
> mostrando cómo será utilizado ese recurso dentro de los periodos de
> tres, seis y doce meses
>
> - Si previamente había un bloque asignado por un proveedor, y se desea
> mantener el mismo para evitar la renumeración, y hay acuerdo entre
> ambas partes, se podrá ceder[2] dicho bloque (con el cambio de
> titularidad en el whois, a través de LACNIC).
>
> - Si se ha justificado espacio adicional y es posible su distribución,
> el receptor podrá decidir si la cesión le es conveniente y recibe un
> bloque por el espacio adicional o prefiere un único bloque por el
> total y, por lo tanto, renumera. En caso de renumeración, el bloque
> previamente asignado deberá ser retornado en un plazo máximo de 12
> meses. Excepcionalmente, este plazo podrá ser extendido en 6 meses
> adicionales si se justifica que no ha habido tiempo para la
> consecución de los recursos que precisa y la renumeración
> correspondiente.
>
> - En caso de que el solicitante aun no cuente con un bloque IPv6
> asignado por LACNIC, solicitar al mismo tiempo un bloque IPv6
> cumpliendo con la política aplicable.
>
> ...
>
> 2.3.3.4.3 - Tamaño de la asignación y procedimiento
>
> El solicitante debe justificar que anunciará el espacio asignado, con
> su propio sistema autónomo, al menos a otro sistema autónomo.
>
> El tamaño de asignación mínima de direcciones IPv4 para un usuario
> final es de un bloque con prefijo /24 y el tamaño máximo será un /20,
> el cual deberá ser justificado, de acuerdo con la tasa de utilización
> (sección 2.3.3.4.2).
>
> Si previamente había un bloque asignado por un proveedor, y se desea
> mantener el mismo para evitar la renumeración, y hay acuerdo entre
> ambas partes, se podrá ceder dicho bloque (con los cambios
> correspondientes en el whois). Si se ha justificado espacio adicional
> y es posible su asignación, el receptor podrá decidir si la cesión le
> es conveniente y recibe un bloque por el espacio adicional o prefiere
> un único bloque por el total y, por lo tanto, renumera. En caso de
> renumeración, el bloque previamente asignado deberá ser retornado en
> un plazo máximo de 6 meses. Excepcionalmente, este plazo podrá ser
> extendido en 6 meses adicionales si se justifica que no ha habido
> tiempo para la consecución de los recursos que precisa y la
> renumeración correspondiente.
>
> Para asignaciones adicionales se seguirán las políticas incluidas en
> la sección 2.3.4 aplicables a los usuarios finales.
>
> *Texto Nuevo*
> 2.3.3.1.1. - Requisitos para un prefijo /24 a un /22
>
> Para calificar para la distribución de un prefijo /24 a un /22 el ISP
> solicitante deberá cumplir los siguientes requisitos
>
> 1. Demostrar el uso o la necesidad inmediata de al menos el 25% del
> prefijo solicitado.
>
> 2. Entregar un plan detallado de uso de 50% de uso del prefijo
> solicitado para un año.
>
> - En caso de que el solicitante aun no cuente con un bloque IPv6
> asignado por LACNIC, solicitar al mismo tiempo un bloque IPv6
> cumpliendo con la política aplicable.
>
> 2.3.3.1.2. - Requisitos para un prefijo /21 o menor (bloque de 8 /24 o
> más)
>
> En caso de que el ISP solicitante requiera una distribución inicial de
> direcciones IPv4 a partir de un prefijo /21 deberá cumplir los
> siguientes requerimientos
>
> - Proveer información de las asignaciones realizadas por prefijos de
> longitudes /29 o menores (más de 8 direcciones IPv4) en el WHOIS de
> LACNIC.
>
> - Proveer documentación justificando la distribución de espacio de
> direcciones inicial. (Llenado de la plantilla de solicitud de
> direcciones IPv4 para ISP). Se deberá incluir información detallada
> mostrando cómo será utilizado ese recurso dentro de los periodos de
> tres, seis y doce meses.
>
> - En caso de que el solicitante aun no cuente con un bloque IPv6
> asignado por LACNIC, solicitar al mismo tiempo un bloque IPv6
> cumpliendo con la política aplicable.
>
> ...
>
> 2.3.3.4.3 - Tamaño de la asignación.
>
> El solicitante debe justificar que anunciará el espacio asignado, con
> su propio sistema autónomo, al menos a otro sistema autónomo.
>
> El tamaño de asignación mínima de direcciones IPv4 para un usuario
> final es de un bloque con prefijo /24 y el tamaño máximo será un /20,
> el cual deberá ser justificado, de acuerdo con la tasa de utilización
> (sección 2.3.3.4.2).
>
> Para asignaciones adicionales se seguirán las políticas incluidas en
> la sección 2.3.4 aplicables a los usuarios finales.
>
> <fin del texto>
>
> Notas:
>
> [1] La discusión no estará restringida solo esta propuesta, si alguien
> quiere opinar sobre otra propuesta es libre de hacerlo. Sin embargo es
> una manera fácil de ordenar la discusión.
>
> [2] Los comentarios durante esta semana se suman a los comentarios ya
> expresados con anterioridad para la decisión del consenso.
>
> Ariel Weher / Tomas Lynch
> Moderadores del Foro de Políticas Públicas de LACNIC
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> .lacnic.net%2Fmailman%2Flistinfo%2Fpoliticas&data=02%7C01%7Cedmund
> o.cazarez%40nic.mx%7C6507bad3153b447b7cca08d7ca77e87a%7Cc65a3ea60f7c40
> 0b89345a6dc1705645%7C0%7C0%7C637200488680535798&sdata=zx%2BD75y5lN
> YcACLL9cFqwa1NM4Qym6dnA1YBOZGVcfI%3D&reserved=0
_______________________________________________
Politicas mailing list
Politicas at lacnic.net
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.lacnic.net%2Fmailman%2Flistinfo%2Fpoliticas&data=02%7C01%7Cedmundo.cazarez%40nic.mx%7C6507bad3153b447b7cca08d7ca77e87a%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C637200488680535798&sdata=zx%2BD75y5lNYcACLL9cFqwa1NM4Qym6dnA1YBOZGVcfI%3D&reserved=0
Este mensaje contiene información confidencial y se entiende dirigido y para uso exclusivo del destinatario. Si recibes este mensaje y no eres el destinatario por favor elimínalo, ya que difundir, revelar, copiar o tomar cualquier acción basada en el contenido está estrictamente prohibido. Network Information Center, S.A. de C.V., ubicado en Ave. Eugenio Garza Sada 427 L4-6 Col. Altavista, Monterrey, México, C.P. 64840 recaba tus datos personales necesarios para: la prestación, estudio, análisis y mejora del servicio, la realización de comunicaciones y notificaciones; la transferencia y publicación en los casos aplicables; el cumplimiento de la relación existente; así como para la prevención o denuncia en la comisión de ilícitos. Si eres colaborador o candidato a colaborador de NIC México, tus datos serán utilizados para: la creación y administración de tu perfil como profesionista; el otorgamiento de herramientas de trabajo; la realización de estudios; el otorgamiento de programas y beneficios para mejorar tu desarrollo profesional; la gestión y administración de servicios de pago y/o nómina; así como para contacto y/o notificaciones. Si participas en promociones o en estudios podrás dejar de participar. Para mayor información revisa el Aviso de Privacidad<http://www.nic.mx/es/NicMx.AvisosDePrivacidad>.
This message contains confidential information and is intended only for the individual named. If you are not the named addressee please delete it, since the dissemination, distribuition, copy or taking any action in reliance on the contents is strictly prohibited. Network Information Center, S.A. de C.V., located on Av. Eugenio Garza Sada 427 L4-6, Col. Altavista, Monterrey, Mexico, CP 64840 collects your personal data which is necessary to: provide, research, analyze and improve the service; send communications and notices; transfer and publish your personal data when applicable; fulfill the existing relationship; prevent or inform in the commission of unlawful acts or events. If the data is processed in your quality of candidate or collaborator of NIC Mexico, the purpose of treatment is to: create and manage your profile as a professional; provide you with working tools; conduct studies; grant benefits and programs to enhance your professional development; manage and administrate payment services and/or payroll; as well as to contact you. If you participate in promotions or surveys you may stop or quit your participation at any time. For more information read the Privacy Note<http://www.nic.mx/es/NicMx.AvisosDePrivacidad>.
_______________________________________________
Politicas mailing list
Politicas at lacnic.net
https://mail.lacnic.net/mailman/listinfo/politicas
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
More information about the Politicas
mailing list