Dominio principal
Infraestructura
En la faceta Dominio principal, los análisis de Infraestructura se agrupan por dominio principal para que los lectores puedan seguir un área concreta de la infraestructura de Internet, la gobernanza, los mercados de conectividad o el capital digital. La página reúne artículos relacionados, evidencia pública, instituciones, empresas, personas, exposición regional, dependencias operativas y contexto de mercado que de otro modo aparecerían en páginas de categoría separadas. Explica el dominio, la clase probable de actor, el contexto de mercado o de gobernanza y el material de origen que los lectores deben usar al comparar señales. Operadores, analistas y lectores de gobernanza pueden ver cómo el mismo dominio aparece en eventos, perfiles, cambios de mercado, evidencia de fuentes públicas, dependencias regionales y decisiones de infraestructura de ciclos más largos a lo largo del tiempo.
IETF
Una concesión temporal de localizador SRv6 incorpora DHCPv6 al plano de control de enrutamiento
Un localizador SRv6 delimita el espacio de direcciones del que un nodo obtiene sus SID. RFC 10038 permite recibir esa base mediante una concesión temporal de DHCPv6. La automatización también traslada autoridad: selección del conjunto de direcciones, renovación, instalación de…
IETF
Que un encabezado esté permitido aquí no lo hace fiable en todas partes: RFC 9878 y el alcance de los P-Headers SIP
La interoperabilidad se rompe cuando un emisor coloca un P-Header en un mensaje SIP que el receptor considera que no debe llevarlo. Un nodo lo elimina, otro rechaza el mensaje y otro lo acepta. La divergencia puede alterar datos de tarificación, red visitada e información de…
Expediente
El titular estaba fuera; el registro del .com estaba en Virginia: CNN contra CNNews.com
La actividad visible estaba en chino, el operador era una empresa china y el nombre circulaba ante un público principalmente chino. Pero el registro que podía ejecutar una orden sobre `.com` seguía en Virginia. En *CNN v. CNNews.com*, esa separación convirtió un dominio en objeto…
IETF
Un enlace no es una ubicación: RFC 9877 y el control de geofeeds en RDAP
Encontrar el enlace de un geofeed indica dónde consultar, no que todas sus afirmaciones de ubicación sean verdaderas. RFC 9877 convierte RDAP en una señal acotada de descubrimiento y autoridad, mientras que el alcance, la vigencia, la autenticidad y la privacidad requieren…
Historia de Internet
La ventana que se negó a abrirse byte a byte: cómo TCP evita el Silly Window Syndrome
El receptor puede disponer de unos pocos bytes libres y, aun así, decidir que todavía no conviene anunciarlos. Esa espera impide que una apertura diminuta se convierta en el metrónomo de todo el flujo.
IETF
Un número de dos bytes puede mentir sobre la carga útil: RFC 9876 y el control del registro CoAP
CoAP define Content-Format como un entero pequeño que identifica el tipo de medio de una carga útil y su posible codificación de contenido. RFC 9876 refuerza el procedimiento de registro asociado: el código solo tiene un significado preciso cuando el tipo de medio, los…
BDNOG
bdNOG publica quién supervisa a su comité ejecutivo, no cómo
Las páginas de gobernanza de bdNOG presentan al Board como la máxima autoridad y al comité ejecutivo (EC) como responsable de la gestión. El Board afirma que aprueba las actividades anuales y que exige responsabilidades al EC. Las páginas revisadas no publican el procedimiento…
IETF
Un resolutor puede elegir el cifrado antes de que los operadores DNS se coordinen
Cifrar la conexión entre un usuario y su resolutor recursivo no protege el salto siguiente. Cuando la respuesta no está en caché, el resolutor todavía puede consultar en texto claro a un servidor autoritativo. RFC 9539 propone un compromiso experimental: permitir que cada parte…
Historia de Internet
La ventana que se cerró sin terminar la conexión: el estado persistente de TCP
Una ventana de recepción en cero detiene el envío normal, pero no declara muerta la conexión. TCP necesitaba una forma de volver a preguntar sin desobedecer el control de flujo.
IETF
Una cabecera puede invalidar toda una sección: RFC 9875 y los grupos de caché HTTP
Una respuesta puede declarar grupos opacos para relacionar respuestas almacenadas dentro de una misma caché y un mismo origen URI. Una solicitud insegura puede señalar esos grupos para una invalidación posible. El límite no es menor: el mecanismo no sincroniza cachés distintas ni…
IETF
Las zonas de catálogo convierten una lista DNS en autoridad de aprovisionamiento para toda la flota
Un archivo vacío suele representar ausencia. En una zona de catálogo DNS puede ser una orden. Si un generador publica por error un catálogo válido sin miembros, los consumidores pueden retirar las zonas que ese catálogo había aprovisionado. La superficie de control no está en los…
Historia de Internet
El número que se volvió más difícil de predecir para un atacante fuera de ruta: números de secuencia iniciales de TCP
Una conexión TCP comienza intercambiando números. El cambio histórico no ocultó ese intercambio: impidió que un número visible revelara el punto de partida de la conexión siguiente.
ICANN
Un archivo de zona ofrece acceso compartido, no permiso para republicar el espacio de nombres
A las nueve de la mañana, un investigador autorizado descarga mediante CZDS el archivo de zona de un gTLD. La suma de comprobación coincide. Eso demuestra la entrega de unos bytes concretos, no quién controla cada nombre, para qué se usa ni si el archivo completo puede volver a…
IETF
Un comando de borrado puede romper el dominio de otro: RFC 9874 y el control de dependencias EPP
Una transición destructiva de EPP puede afectar mucho más que al cliente que la solicita. Si un host subordinado sigue asociado con dominios patrocinados por otros clientes, borrarlo puede alterar sus dependencias DNS, provocar fallos de resolución y dejar inconsistencias entre…
IETF
La segunda dirección pasó a ser la principal: qué cambia RFC 9873 en los contactos EPP
Una actualización de contacto EPP puede cambiar el estado de forma explícita: el objeto puede contener una dirección de correo adicional y el atributo opcional `primary` señala cuál debe tratarse como principal. El protocolo registra esa relación, pero no certifica la propiedad…
IETF
El rechazo por defecto convierte la ausencia de política eBGP en un fallo explícito
Una sesión BGP externa puede estar establecida aunque siga sin definirse la autoridad para recibir o anunciar rutas. RFC 8212 cierra esa ambigüedad: sin política de importación no se acepta ninguna ruta; sin política de exportación no se anuncia ninguna. La cuestión directiva no…
Historia de Internet
La cadena que hizo creíble una clave pública: gestión de certificados PEM
Una clave pública no demuestra por sí sola a quién pertenece. RFC 1422 situó esa decisión dentro de una arquitectura de certificados, autoridades de certificación, rutas de validación e información de revocación para Privacy Enhanced Mail.
IETF
El uRPF mejorado admite rutas de origen factibles sin confiar en todas las rutas
Un paquete legítimo de un cliente multihomed puede llegar por un enlace distinto del que el router elegiría para volver al origen. El control estricto puede descartarlo; el laxo puede aceptar cualquier origen enrutado. RFC 8704 define un límite intermedio: construir por interfaz…
IETF
El prefijo llegó antes que la consulta: cómo RFC 9872 cambia el descubrimiento de NAT64
Un equipo conectado a una red solo IPv6 necesita conocer el prefijo que la red usa para sintetizar direcciones destinadas a servicios IPv4. RFC 9872 convierte ese dato en una señal de acceso: PREF64 debe aprenderse primero por anuncios de router y solo después, si hace falta…
Tendencias de telecomunicaciones nacionales de Europa y Oriente Medio
Un teléfono satelital guardado no es un respaldo local hasta ensayar servicio, despliegue y ruta de llamada
Un teléfono satelital puede aportar diversidad cuando fallan las redes terrestres. Tenerlo registrado y guardado no demuestra que el equipo de guardia pueda encenderlo, desplegarlo, obtener servicio y completar la llamada prevista.