Resumen

  • El Borrador 1 de «Multihoming not required for ASN» sustituyó una condición acumulativa por dos vías alternativas: ser multihomed o necesitar interconectarse con otro sistema autónomo, también mediante un plan próximo. Conservó tanto la orientación hacia ASN privados cuando no hiciera falta unicidad pública como la evaluación conforme a RFC 1930 o sus sucesores.
  • La propuesta distinguió correctamente la función de un ASN —coordinar una identidad de encaminamiento globalmente única— de una topología concreta. Obligar a comprar un segundo tránsito podía excluir a redes pequeñas, remotas o de tránsito único aun cuando una interconexión, un IXP, el espacio independiente del proveedor o una exigencia operativa justificaran una identidad pública.
  • La objeción benigna era real: algunas redes con un solo proveedor pueden operar con ruta estática o ASN privado. El debate de marzo y la evaluación del personal del 8 de abril mostraron que «necesidad de interconectarse» era demasiado impreciso y chocaba con la orientación de RFC 1930 sobre sitios single-homed.
  • La solución no era restaurar la redundancia obligatoria ni eliminar toda comprobación. Era formular una prueba estrecha de necesidad de coordinación global, exigir evidencia pertinente, dar razones coherentes y permitir revisión. AFRINIC podía administrar ese servicio como registro técnico privado; no podía convertirlo en autoridad sobre el diseño de una red.

La factura escondida en una condición técnica

Imaginemos un operador en una ciudad secundaria donde llega un solo proveedor de tránsito con condiciones comercialmente viables. La empresa dispone de espacio de direcciones independiente del proveedor y quiere que su identidad de encaminamiento no cambie cada vez que renegocie el acceso. También proyecta conectarse a un punto de intercambio de tráfico, o mantener una interconexión privada con una red vecina, aunque su salida general a Internet siga dependiendo de un único tránsito. Nada de eso convierte por arte de magia su infraestructura en multihomed.

Sí puede crear, en cambio, una necesidad concreta de que los demás participantes reconozcan una identidad pública distinta y estable. Bajo la condición heredada, el operador se enfrentaba a una elección absurda: comprar una segunda conexión que quizá no necesitaba, que tal vez ni siquiera estaba disponible, o renunciar al identificador requerido para otra función técnica.

Ese era el problema práctico que el Borrador 1 puso sobre la mesa. Su fecha de presentación fue el 27 de febrero de 2019. La página oficial conservada en archivo lo identifica como Versión 1.0, atribuye la autoría a Jordi Palet Martinez y marca su estado como «Under Discussion». AFRINIC comunicó la recepción al foro RPD el 7 de marzo y explicó que el objetivo era retirar el multihoming como requisito previo para asignar un número de sistema autónomo. Las fechas describen actos distintos: primero la presentación; después el anuncio público y la invitación a comentar. Ninguno equivale a aprobación, ratificación o entrada en vigor.

La propia documentación presenta una irregularidad que conviene conservar, no corregir en silencio. La página archivada imprime el identificador AFPUB-2019-ASN-DRAFT01. La evaluación del personal de abril utiliza AFPUB-2019-ASN-001-draft-01, y la cadena posterior de la propuesta consolidó la forma AFPUB-2019-ASN-001-DRAFT01. Este análisis usa esa última forma normalizada para designar el expediente, pero la diferencia gráfica forma parte del rastro documental. No altera el contenido del primer borrador; sí recuerda que una reconstrucción rigurosa debe separar lo que aparece en cada fuente de la nomenclatura que terminó prevaleciendo.

La regla heredada funcionaba como una conjunción. El solicitante debía cumplir todas las condiciones enumeradas, entre ellas demostrar una política de encaminamiento única y ser un sitio multihomed, o presentar un plan próximo para reunirlas, además de mantener la condición exigida de miembro en buena situación. En términos lógicos, el multihoming no era una señal posible entre varias. Era una puerta obligatoria dentro de un conjunto acumulativo. Una red podía tener una razón perfectamente identificable para aparecer con una identidad autónoma ante otra red y, aun así, fallar la prueba porque no había contratado dos proveedores físicos.

El Borrador 1 alteró esa estructura. Propuso que un miembro en buena situación pudiera satisfacer una de dos vías: ser multihomed o demostrar que necesitaba interconectarse con otro sistema autónomo. También contemplaba el plan próximo para alcanzar una u otra situación. El cambio de una conjunción a una alternativa era pequeño sobre la página y grande en sus efectos conceptuales. Ya no se presumía que toda necesidad legítima de identidad global debía manifestarse mediante dos tránsitos. Una interconexión podía ser la circunstancia que hiciera necesario el identificador, aun cuando el diseño general de la red siguiera siendo single-homed.

La propuesta no eliminaba todas las barreras. Conservaba la indicación de que los sitios que no necesitaran un ASN globalmente único debían usar números privados. Mantenía asimismo la referencia a la evaluación conforme a RFC 1930 o a sus sucesores. Incluía otros cambios editoriales: suprimía una subsección introductoria y consolidaba o renumeraba la sección 7. Esos ajustes son parte del expediente, pero el mecanismo sustantivo estaba en el nuevo «o». La pregunta dejó de ser únicamente si el operador había construido redundancia física y pasó a incluir si requería interconectarse con otro AS.

Esa distinción importa porque un ASN no es un certificado de buena arquitectura. Es un identificador usado para distinguir un dominio administrativo de encaminamiento allí donde la coordinación pública exige que esa identidad sea única. El multihoming puede constituir evidencia poderosa: dos proveedores que reciben y aplican políticas diferentes suelen requerir una identidad autónoma visible. Pero la coincidencia frecuente entre una necesidad y una topología no convierte la topología en el objeto de la asignación.

Confundir ambas cosas es como exigir dos carreteras de acceso para expedir una matrícula: la redundancia puede ser deseable, pero no explica por sí sola la función del identificador.

El primer intercambio sustantivo de marzo expuso las dos mitades del problema. Jaco Kroon formuló la objeción más fuerte a una apertura excesiva: un sitio conectado a un solo proveedor puede ser servido mediante una ruta estática y, por tanto, no necesitar un ASN público. La observación no era una defensa necesaria de toda la regla antigua. Era una advertencia de higiene de encaminamiento.

Si una identidad solo ha de ser única dentro de una relación administrativa local, un ASN privado puede bastar; si el proveedor puede anunciar la ruta agregada sin que el cliente opere una política exterior distinta, la asignación pública puede no aportar nada.

Fernando Frediani respondió con casos que la ruta estática no agota. Una red puede querer mantener espacio independiente del proveedor para no renumerar cuando cambie su relación comercial. Puede prever otro proveedor aunque hoy solo tenga uno. Puede conectarse a un IXP o establecer una interconexión privada mientras conserva un único tránsito para el resto del tráfico. En esos supuestos, «un solo upstream» no significa «una sola relación de encaminamiento» ni «ninguna necesidad de identidad global». La respuesta tampoco prueba que toda red con espacio independiente merezca automáticamente un ASN.

Demuestra algo más limitado y más importante: contar proveedores no es una prueba exhaustiva de la función técnica que desempeñará el número.

Días después, Owen DeLong propuso en la lista una formulación más directa basada en una política de encaminamiento única o en una interconexión mediante un protocolo de gateway exterior que exigiera un ASN único. Sander Steffann apoyó esa dirección. Esa redacción perteneció al debate; no debe insertarse retrospectivamente en el texto publicado del Borrador 1. Su importancia histórica dentro de este episodio está en mostrar que los participantes detectaron pronto la insuficiencia de la palabra «necesidad». Interconectarse puede significar muchas cosas.

No toda conexión entre redes requiere que cada parte posea un ASN público propio, y no toda relación con un único tránsito elimina esa necesidad.

La evaluación del personal del 8 de abril convirtió esa tensión en un problema de aplicación. Señaló que la sección 5.1 de RFC 1930 afirmaba que un sitio single-homed no necesitaba un ASN único, mientras que la vía de interconexión del Borrador 1 podía permitir una asignación en un caso de una sola conexión. Si el texto seguía remitiendo a RFC 1930, ¿qué orientación debía controlar la decisión? No era una objeción semántica menor. Dos revisores podían leer los mismos materiales y llegar a respuestas contrarias: uno aprobaría porque existía interconexión; otro denegaría porque el sitio era single-homed conforme a la guía citada.

El personal planteó cuatro escenarios de solicitudes relacionados con un solo par o con peering previsto. La utilidad de esos escenarios no depende de fingir que fueron casos reales ni de inventar resultados. Eran pruebas hipotéticas para verificar si el nuevo criterio producía decisiones inteligibles.

La evaluación también pidió que se usara la expresión correspondiente a «resource member», anticipó mayor consumo de ASN pero no un problema previsible para el conjunto de 32 bits, dejó constancia de que no había comentario del asesor jurídico e identificó trabajo operativo en el proceso de solicitud, los formularios, las listas de comprobación y la documentación. En otras palabras, el cambio no terminaba al sustituir una línea: exigía decidir qué evidencia recogería el registro y cómo explicaría sus respuestas.

El espacio ampliado de ASN de cuatro octetos reduce la fuerza de una objeción basada exclusivamente en escasez inmediata, como ayuda a entender RFC 6793. Pero esa ampliación no convierte todo uso en sensato. RFC 6996 reserva rangos para uso privado precisamente porque muchas relaciones no necesitan unicidad global. El Borrador 1 todavía imprimía el rango privado anterior y se refería en general a RFC 1930 o sus sucesores; no contenía ya la redacción técnica de las versiones posteriores ni un cálculo de miles de años.

La conclusión prudente es doble: el agotamiento del conjunto de 32 bits no parecía un riesgo cercano para el personal, y aun así seguía siendo legítimo evitar asignaciones públicas carentes de función coordinativa.

Para el operador pequeño, la diferencia entre ambas pruebas era económica antes que retórica. Un segundo upstream implica pagos recurrentes de acceso y tránsito, equipo adicional, configuración, monitorización y capacidad humana para operar la redundancia. En algunos lugares el proveedor alternativo no existe; en otros recorre la misma infraestructura física y ofrece una redundancia nominal. Las empresas grandes pueden absorber el coste como parte de una estrategia más amplia.

Para una red comunitaria, una institución educativa, un operador local o una empresa de un mercado periférico, el mismo requisito fijo puede consumir una proporción desmedida de su presupuesto.

No hay en el expediente sellado una cifra de ese coste ni un solicitante identificado al que AFRINIC hubiera denegado el número. Tampoco se sabe cuántas organizaciones fueron disuadidas antes de presentar una solicitud. Sería incorrecto transformar una consecuencia plausible del diseño en una estadística. Lo que sí puede afirmarse es el mecanismo: si una condición obliga a contratar infraestructura no necesaria para la finalidad del identificador, añade un coste de entrada ajeno a esa finalidad.

El análisis de Heng Lu sobre la penalización de la pobreza ayuda a ver por qué una obligación aparentemente igual pesa de forma desigual cuando los mercados, las distancias, el capital y las opciones de suministro son distintos.

La estabilidad también tiene valor económico. El espacio independiente del proveedor y una identidad pública pueden reducir el coste de renumerar y la dependencia de un suministrador. Pueden facilitar el intercambio local de tráfico o una transición futura. Esos beneficios no aparecen en todas las redes, y un proveedor que pida un ASN no tiene razón técnica por el mero hecho de pedirlo. Pero una política que solo pregunta por dos enlaces ignora el mecanismo de dependencia.

Obliga al solicitante a representar el futuro de su red mediante una compra presente, aun cuando pudiera demostrar de manera más directa por qué la coordinación pública es necesaria.

La fuente comparativa de APNIC, que el propio Borrador 1 citaba en relación con retirar el multihoming obligatorio, muestra que el problema no era inconcebible fuera de la región. No prueba que AFRINIC tuviera que copiar la solución de otro registro, ni que los procesos fueran equivalentes. Sirve para confirmar que separar elegibilidad y multihoming era una cuestión técnica debatida entre registros, no una licencia para atribuir al primer borrador efectos que todavía no había producido.

Visto desde la continuidad operativa, el análisis de LARUS aporta otra pieza. Las reglas de elegibilidad y el tiempo que tarda su interpretación pueden cambiar decisiones de infraestructura aunque el registro no toque ningún router. Un operador que no sabe si obtendrá una identidad estable puede posponer una interconexión, aceptar numeración controlada por un proveedor o contratar una conexión superflua para encajar en el formulario. No hace falta afirmar que esos resultados ocurrieron en una empresa determinada.

Basta reconocer que la administración de identificadores tiene un canal de impacto concreto: condiciona las alternativas que el operador puede preparar y el coste de conservarlas.

Por eso el Borrador 1 merece atención aunque no fuera adoptado como tal. Identificó una contradicción real entre la finalidad del recurso y el indicador que se había usado para concederlo. Al mismo tiempo, la reacción de marzo y la evaluación de abril mostraron que sustituir un proxy claro por una frase abierta podía desplazar el problema. La coerción visible de «compre otro enlace» podía convertirse en la discreción menos visible de «convénzame de que necesita interconectarse». La reforma correcta requería preservar la apertura conceptual y cerrar la ambigüedad probatoria.