Resumen

  • La venta de conectividad dedicada demuestra una relación de servicio, pero no basta para demostrar que el cliente recibió un bloque IPv4.
  • El debate público de septiembre recoge una observación sobre portales y un ejemplo de un ISP brasileño, sin afirmar que las direcciones cambiaran de manos ni resolver cómo clasificar el caso.

El 14 de septiembre, un participante de la lista de políticas de LACNIC preguntó por qué una opción de subasignación aparecía en MiLACNIC pero no en Registro.br, y si había un plazo. Al día siguiente, un participante de Registro.br describió el trabajo entre LACNIC y los registros nacionales de Internet para poner en marcha la política, y recordó que cada sistema también afronta sus propios problemas. Otra respuesta señaló que la opción era visible en MiLACNIC para un ASN que el autor conocía, aunque todavía no había tenido que utilizarla. El motivo de la pregunta, añadió, era un caso real: un proveedor brasileño vendía un enlace dedicado a una empresa no brasileña. (pregunta del 14 de septiembre; respuesta sobre la puesta en marcha; aclaración del caso)

El ejemplo es concreto. También se detiene justo antes de los datos necesarios para llegar a una conclusión normativa. El mensaje no dice que el proveedor entregara un prefijo al cliente, que este originara rutas, que tuviera un número de sistema autónomo o que alguna dirección cambiara de titular. Tampoco ubica la red del cliente. Un enlace dedicado acredita un servicio de conectividad; por sí solo, no acredita que el cliente recibiera un recurso de numeración.

Esa distinción es el centro de LAC-2025-5, la política de LACNIC «Subasignación de recursos IPv4 a terceros». La página oficial registra su ratificación el 24 de marzo de 2026. El texto vigente se limita a IPv4 y establece condiciones para que una subasignación califique: requisitos del destinatario, límites al tamaño del bloque, criterios de uso o necesidad inmediata, vínculo en WHOIS entre el bloque y el ASN del destinatario, y un evento en el registro público de movimientos. La responsabilidad última permanece en el miembro de LACNIC que subasigna. También se establece una espera después de una transferencia o recuperación de recursos. (texto ratificado vigente)

Estas salvaguardas no convierten cada conexión de cliente en una transferencia de recursos. Al contrario: hacen más importante clasificar correctamente la relación subyacente. Si el proveedor vende transporte y sigue usando su propio espacio de direcciones, comprar un circuito dedicado no basta para demostrar una subasignación. Si además pone un bloque bajo el uso operativo del cliente, llamar «enlace» al servicio no elimina esa relación. Los mensajes públicos no aportan suficientes detalles para distinguir entre ambos supuestos.

La prueba se refiere al recurso, no al nombre comercial

La guía de LACNIC para solicitar recursos ayuda a mantener separadas las categorías. Sitúa en el contexto de un proveedor de Internet a quienes ofrecen servicios como alojamiento web, colocación, servidores virtuales o enlaces dedicados. También distingue a la organización que opera su propia infraestructura sin reasignar bloques de direcciones a terceros. Las solicitudes de Brasil y México se tramitan a través de sus respectivos registros nacionales de Internet. (guía de solicitudes de LACNIC)

La guía no clasifica el caso de la lista. Sí muestra por qué «enlace» es un sustituto impreciso de la pregunta de política. Un circuito describe lo que compra el cliente: conectividad entre puntos de una red. Un registro de recursos describe otro objeto: qué organización recibe el bloque IPv4 y qué prueba vincula a esa organización con el recurso. Un contrato o una factura pueden incluir ambos; también puede existir uno sin el otro.

La frontera es habitual en la economía de infraestructura. Las empresas agrupan capacidad, equipos, operación y direccionamiento porque el cliente suele querer un resultado, no una lista de insumos que deba gestionar por separado. El paquete reduce costes de coordinación. También puede ocultar quién controla un insumo escaso y quién asume las obligaciones registrales asociadas. La respuesta no es presumir que todo servicio combinado incluye una subasignación. Es identificar el recurso y a su destinatario antes de aplicar una norma concebida para esa relación.

LAC-2025-5 concreta el examen. El bloque debe encontrarse dentro del intervalo de tamaño que establece el texto vigente. El destinatario debe cumplir las condiciones de ASN e IPv6. El umbral de utilización separa el uso existente o la necesidad inmediata de un plan para alcanzar el nivel superior en un año. WHOIS debe asociar el bloque con el ASN del destinatario, y el registro público debe consignar el bloque, el ASN, la fecha y el inicio o fin del evento. El miembro que subasigna conserva la responsabilidad última. No son indicadores genéricos de una relación comercial: son campos de un mecanismo concreto de gobernanza de recursos.

La nacionalidad del cliente tampoco describe su red. «Empresa no brasileña» informa sobre la compañía tal como la presenta el participante, pero no sitúa sus routers, sus usuarios ni el espacio de direcciones que utiliza. Tampoco revela si el cliente tiene un ASN o usa direcciones del proveedor. La geografía puede determinar qué registro nacional interviene; no sustituye los datos del destinatario y del recurso que exige la política.

Una diferencia entre portales plantea una pregunta, no prueba un fallo

El hilo de septiembre debe leerse como evidencia de implementación con alcance limitado. El 1 de septiembre, el asistente de políticas de LACNIC había dicho que se esperaba implementar la regla antes de fin de año, primero en sus aspectos básicos, mientras seguían pendientes desafíos técnicos. Después, un participante indicó que veía una opción en un sistema, pero no en otro. Una respuesta mencionó el trabajo conjunto y los problemas propios de cada sistema. Otra persona dijo que la opción aparecía para un ASN conocido, aunque no la había utilizado. (nota de implementación del 1 de septiembre)

En conjunto, los mensajes muestran que los usuarios intentaban averiguar cómo aparecería la política en distintas interfaces mientras el despliegue seguía en curso. No demuestran que un portal estuviera averiado, que la opción estuviera disponible para todas las cuentas de MiLACNIC, que ya tuviera que aparecer en Registro.br ni que se hubiera incumplido un plazo. Son observaciones fechadas y explicaciones, no una prueba controlada del funcionamiento de los sistemas.

La dificultad práctica, sin embargo, es real: una política que depende de un destinatario, un bloque, un ASN y un evento fechado debe poder usarse por los miembros y, cuando corresponda, por los NIR. Si una cuenta no encuentra la opción, una solicitud puede demorarse o quedar en duda. Pero el coste debe medirse con casos comprobados, no deducirse de un intercambio. La elegibilidad de la cuenta, la relación con el recurso, el calendario del despliegue y la experiencia del usuario son explicaciones posibles hasta que el operador confirme cuál aplica.

La secuencia más eficiente empieza por el recurso. Primero se identifica el bloque. Después, quién lo recibe o controla, el ASN del destinatario y el registro pertinente. Luego se comprueba si se cumplen las condiciones de la política y si se requiere un evento público. Solo entonces tiene sentido preguntar si el portal permite registrar ese evento. Partir de un menú que falta e inferir una subasignación convierte una incertidumbre de interfaz en una conclusión jurídica o técnica.

Esta disciplina protege a ambas partes. Un proveedor no debería tener que registrar un evento de recursos solo porque un cliente compra un circuito dedicado, si no existe una relación de subasignación que cumpla la política. Pero el cliente y el registro tampoco deberían quedarse sin constancia cuando el proveedor coloca realmente un bloque bajo el uso del cliente solo porque el contrato lo llama enlace o servicio gestionado. La prueba está en la asignación y el control reales del bloque, documentados con la evidencia que especifica la política.

Qué debería mostrar una constancia útil de implementación

Para el miembro, un flujo fiable debería hacer visible la relación antes del envío: el bloque, el destinatario previsto, su ASN, la base de uso o necesidad inmediata y la fecha de inicio o cierre. Si la política aplica, los datos del registro y la entrada del log público deberían coincidir. Si no aplica porque el proveedor conserva las direcciones y no ha reasignado un bloque, esa explicación debería resultar igualmente clara para el cliente y para quien atienda la solicitud.

Para LACNIC y los NIR, la cuestión no es solo si aparece un botón. El miembro debe saber qué sistema es el adecuado para su cuenta, si el flujo permite completar los campos necesarios y si el evento enviado puede contrastarse con el registro del recurso. El intercambio de septiembre no responde a esas preguntas. Una próxima actualización podría hacerlo si describe las etapas del despliegue, las responsabilidades de cada portal y la ruta para las cuentas o recursos administrados por un NIR.

Esto no exige publicar contratos ni datos confidenciales de clientes. La propia política prevé un evento público con campos definidos. Una constancia operativa puede mostrar los campos y el estado del sistema sin divulgar condiciones comerciales. Si no hay subasignación que cumpla los requisitos, puede bastar una respuesta privada de asistencia; el registro público no debería sugerir que ocurrió un evento inexistente.

La conclusión es acotada, pero relevante. Un enlace dedicado puede transportar direcciones, y una oferta comercial puede combinar varios insumos de red. Aun así, la respuesta no está en el nombre comercial del servicio, en la nacionalidad del cliente ni en la presencia de una opción en el portal. Depende de quién recibe el recurso IPv4, de cómo queda documentada esa relación y de si se cumplen las condiciones vigentes. La evidencia pública plantea la pregunta; no la resuelve.

Versiones oficiales de LAC-2025-5