jueves, 13 de agosto de 2026
viernes, 31 de julio de 2026
No recibes IPv6 cuando haces tethering
Situación
No recibes IPv6 en tu computadora a pesar de que tú teléfono si tiene IPv6 provisto desde la empresa celular.
Solución
En la parte de configuración de redes móviles --> APN revisa si "APN roaming protocol" lo tienes así
En caso afirmativo NO te funcionará.
La manera correcta es la siguiente:
En lo personal nunca imaginé que el APN roaming protocol fuera el problema pero si lo es.
Espero sea útil.
viernes, 24 de julio de 2026
Video: Todo lo que necesitas saber sobre los prefijos bogons
Hoy queremos aprender. ¿Sabes qué son los prefijos bogons y por qué representan un riesgo para tu red? En este video analizamos a fondo el concepto de prefijos bogon, su clasificación y los ejemplos más comunes tanto en IPv4 como en IPv6. Además, exploramos los principales problemas de seguridad que ocasionan (como el IP spoofing, SPAM, DDoS, etc) y te mostramos las soluciones definitivas para filtrarlos y proteger tu infraestructura de enrutamiento.
domingo, 17 de mayo de 2026
¿Correlación absurda o curiosa? IPv6 & felicidad
Luego de usar el reporte de “World Happiness Report y las estadísticas de penetración de IPv6 de google me he conseguido que existe un grado de correlación de 0.4648. Ahora bien, ¿Qué sígnifica este número?
- En estadística, la correlación se mide en una escala de -1 a 1.
- El 0 significa que no hay ninguna relación.
- El 1 significa una relación perfecta.
- El -1 es que las variables son inversamente proporcionales.
- Un valor de 0.4648 se considera una correlación moderada. Los dos datos se mueven juntos con cierta frecuencia, pero no de forma idéntica.
- Al ser un número positivo (+0.4648), la relación es directa.
- Esto significa que a mayor porcentaje de IPv6 en un país, mayor tiende a ser su puntuación de felicidad.
¿No me creen? Miren la gráfica de abajo.
¿Qué nos dice la gráfica?
Se observa que los países que logran superar el 40% o 60% de adopción IPv6 nativo casi nunca tienen niveles de felicidad críticamente bajos (pocos bajan de una puntuación de 5).
Si.., se que suena loco pero fue una tarea divertida.
¿Qué opinas?
Info
[1] World Happiness Report: 'https://files.worldhappiness.report/WHR26_Data_Figure_2.1.xlsx?_gl=1*zmm7kk*_gcl_au*MzI5Nzg1NTM4LjE3Nzg5NTQ3Mjk.'
[2] Google IPv6 stats: i'https://www.google.com/intl/en_ALL/ipv6/statistics/data/worldmap.js'
[3] Disponible en google colab aquí: https://colab.research.google.com/drive/1G8-KObej157c75lNl8kGzywWkBh1VhoW#scrollTo=87c9d1a2
miércoles, 29 de abril de 2026
fig.show() de Plotly no funciona en jupyter
Escenario:
fig.show() de Plotly no funciona en jupyter
Solución:
Forzar el renderizado agregando esta línea justo antes del fig.show() con pio
Ejemplo:
import plotly.io as pio
pio.renderers.default = 'iframe'
fig.show()
Listo!
jueves, 2 de abril de 2026
FRR: Cómo solucionar la falta de redistribución de rutas kernel al arrancar
Si usas FRRouting (FRR), es posible que te hayas topado con un comportamiento frustrante: tras un reinicio, las rutas del kernel (como una ruta por defecto estática) no aparecen en tus anuncios de RIP o OSPF, pero si reinicias el servicio manualmente, todo funciona de maravilla.
Aquí te explicamos por qué sucede y cómo arreglarlo permanentemente.
El Problema
Al arrancar el sistema, FRR inicia sus procesos (Zebra, RIPd, etc.), pero las rutas definidas a nivel de sistema operativo no se redistribuyen a los vecinos de red. Esto interrumpe la conectividad tras un reboot y obliga a una intervención manual (systemctl restart frr), lo cual es inaceptable en entornos de alta disponibilidad.
El Motivo: La "Carrera" del Arranque
El culpable suele ser una condición de carrera (race condition) entre el gestor de red (como Netplan o systemd-networkd) y FRR.
Renombrado de Interfaces: Herramientas como Netplan a menudo renombran interfaces durante el arranque. Si FRR arranca mientras una interfaz aún se llama eth0 pero está pasando a ser wan0, Zebra puede ignorar las rutas asociadas a esa interfaz.
Estado "Down": Si Zebra escanea la tabla de rutas del kernel antes de que la interfaz de salida esté marcada como "UP" y operativa, RIP considera que la ruta no es válida para ser redistribuida.
Orden de Dependencias: Por defecto, el servicio de FRR puede intentar cargar antes de que la red esté "totalmente en línea", causando que el anuncio inicial de rutas falle.
Paso a paso: La Solución
La solución definitiva consiste en ajustar la unidad de systemd para que FRR espere a que la pila de red esté completamente lista y los nombres de interfaces sean definitivos.
1. Editar la configuración del servicio
No edites directamente el archivo en /lib/systemd/system/. Es mejor usar un override:
bash
sudo systemctl edit frr.service
Usa el código con precaución.
2. Forzar la dependencia de red
En el editor que se abre, añade las siguientes líneas:
ini
[Unit]
After=network-online.target
Wants=network-online.target
Usa el código con precaución.
Esto asegura que FRR no se ejecute hasta que el sistema reporte que la red está operativa (network-online.target).
3. Recargar y verificar
Guarda los cambios y aplica la nueva configuración:
bash
sudo systemctl daemon-reload
Usa el código con precaución.
(ya aquí el problema solucionado)
4. Verificar en FRR
Asegúrate de que tu configuración de FRR tenga los comandos de depuración para confirmar que Zebra recibe las rutas tras el próximo reinicio:
vtysh
debug zebra kernel
debug rip events
show ip route
Conclusión
En sistemas modernos donde el direccionamiento y el nombrado de interfaces son dinámicos (como en la mayoría de las distros Linux actuales), el orden de arranque lo es todo. Forzar a FRR a esperar a la red garantiza que, cuando el daemon pregunte por las rutas del kernel, el sistema ya tenga la respuesta correcta lista.
domingo, 29 de marzo de 2026
Solución a: "Grader Error: Grader feedback not found" en coursera
Situación:
Se recibe "Grader Error: Grader feedback not found" en coursera al enviar una tarea
Solución
Con el error presente
1) Haz clic en el botón de Help (signo de interrogación) en la esquina superior derecha del laboratorio.
2) Selecciona Get latest version y luego Update Lab. Esto generará un notebook nuevo con los metadatos correctos.
jueves, 26 de marzo de 2026
Chistes informaticos de redes
Cierto , hacen bromas de todo tipo...
Chistes broadcast para todo el mundo
Chistes multicast solo para los suscritos al grupo
Cuentan chistes Token Ring por turnos
Chistes NAT pero tendria que traducirlos
Os contaria un chiste NTP pero no tengo tiempo
Os cuento un chiste ICMP, responded si lo habeis pillado
Me gustan mas lo chistes UDP porque fluye el humor aunque se pierdan matices. 🤣
martes, 3 de marzo de 2026
OpenVPN no abre en MAC
Escenario
Tienes una MAC; el cliente OpenVPN pero el mismo no se ejecuta. Típico escenario es que al reiniciar la laptop otro usuario entra a su perfil, y luego al tu querer usar tu perfil sencillamente OpenVPN no abre.
Solución
Ejecuta este script bash con sudo o como root:
-- cut here --
sudo launchctl bootout system /Library/LaunchDaemons/org.openvpn.client.plist
sudo launchctl bootstrap system /Library/LaunchDaemons/org.openvpn.client.plist
# 1. Mata todos los procesos de cualquier usuario
sudo pkill -9 -f "OpenVPN Connect"
sudo pkill -9 -f "ovpnagent"
# 2. Borra el archivo de comunicación bloqueado por el otro usuario
sudo rm -f /var/run/agent_ovpnconnect.sock
# 3. Reinicia el servicio de fondo
sudo launchctl kickstart -k system/org.openvpn.client
sudo launchctl enable system/org.openvpn.client
sudo launchctl bootstrap system /Library/LaunchDaemons/org.openvpn.client.plist
#. Lanza la interfaz de nuevo
open /Applications/OpenVPN\ Connect/OpenVPN\ Connect.app
-- cut here --
Espero haya sido útil
jueves, 26 de febrero de 2026
Análisis, simulación, python, IA, estadística y el juego de dominó, ¡todo en uno!
¿Te gusta jugar dominó en parejas?
Si es así, te invito a conocer mi nuevo blog Simulación 1‑6‑8. En él combino la diversión del dominó con la potencia de la simulación en Python 3, todo ejecutado en Google Colab y apoyado por IA y estadística.
Generalmente hacemos 168 simulaciones para diversos escenarios y te mostramos los resultados de una manera sencilla y entendible. No te pierdas ningún post y aprende desde ya en: https://simulacion168.acostasite.com/
jueves, 15 de enero de 2026
SSH a Telnet
Contexto:
El día de ayer me hicieron una consulta interesante.
Primero, hoy en día nadie quiere usar telnet por temas de seguridad.
Segundo, algunos equipos IoTs solo pueden ser accedidos por telnet
¿Cómo hago para que desde Internet se pueda seguir accediendo dichos equipos pero aumentando la seguridad?. La solución sería como un proxy SSH a Telnet cerca de la red de los equipos IoT
Topología:
Internet -- "Proxy SSH - Telnet" -- Equipos IoTs Telnet-Only
Solución:
La solución es muy sencilla. El Proxy SSH - Telnet que sea un servidor SSH en Linux (Debian, Ubuntu, Alpine, lo que sea).
Y desde el cliente en Internet se haría algo como:
ssh -tt user@192.168.12.1 "telnet 192.168.23.30"
Explicación técnica
Según documentación de ssh:
-t Fuerza la asignación de pseudoterminal. Esto permite ejecutar programas arbitrarios basados en pantalla en una máquina remota, lo cual puede ser muy útil, por ejemplo, al implementar servicios de menú. Varias opciones -t fuerzan la asignación de tty, incluso si ssh no tiene tty local.
Espero sea útil
miércoles, 3 de diciembre de 2025
IPv6 en casi un comercial de compras por TV (panegírico tech)
Un video panegírico con humor imperdible
jueves, 23 de octubre de 2025
Pequeño Bash script para bajar todo Docker y ContainerLAB
¿Has tenido la necesidad de bajar todo containerlab en un server?
¿Es complicado por qué son muchos usuarios y muchos contenedores dockers?
¿Reiniciar y aún ves máquinas corriendo y diferentes instancias?. Este script es para tí
---- cut here ----
#filename: bajar-todo-containerlab.sh
sudo containerlab destroy --all
sudo docker stop $(sudo docker ps -q --filter "label=containerlab")
sudo docker rm $(sudo docker ps -aq --filter "label=containerlab")
sudo ip link delete clab-bridge
sudo systemctl restart docker
---- cut here ----
Ejecuta: sudo bash bajar-todo-containerlab.sh
Espero sea útil
lunes, 15 de septiembre de 2025
Manos a la obra - Nuevo espacio de Documentación IPv6: Un Enfoque Práctico (3FFF::/20)
Introducción
El 23 Julio de 2024 la IANA asignó el bloque de direcciones 3FFF::/20 como un nuevo espacio de direccionamiento para documentación de IPv6, agregando así un nuevo bloque de direcciones al ya existente (2001:db8::/32). Esta solicitud fue realizada en el draft https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3849-update/05/ que reza de la siguiente manera (traducido al español):
“El documento describe la reserva de un prefijo de dirección IPv6 adicional para su uso en la documentación. Esta actualización del RFC 3849 amplía el bloque de direcciones 2001:db8::/32 existente con la reserva de un prefijo adicional más grande. La adición de un /20 permite que los ejemplos documentados reflejen fielmente una gama más amplia de escenarios de implementación realistas y actuales y se alinean más estrechamente con los modelos de asignación contemporáneos para redes grandes”.
A raíz de esta ampliación, desarrollaremos en este artículo un plan de direccionamiento IPv6 a modo de ejemplo, con el bloque de direcciones 3FFF::/20.
Importancia de un Plan de Direccionamiento IP
¿Qué es un plan de direccionamiento IP (v4|v6)?
Un plan de direccionamiento IP se define como el modo, las acciones o el modelo sistemático para llevar a cabo las asignaciones de direcciones IP en una red [1].
¿Por qué debo hacer un plan de direccionamiento IP?
- Ayuda a mantener el orden en la documentación de la red.
- Políticas de asignación más fáciles de implementar.
- Ayuda en el crecimiento ordenado de la red (asignaciones futuras/escalamiento)
- Eficiencia en el performance de la red (tablas de rutas más pequeñas).
- Facilita el Troubleshooting.
- Gestión más sencilla de la red.
¿Cómo debe ser el plan de direccionamiento IP? ¿Qué debo buscar en él?
- Debe ser escalable (imaginemos cómo crecerá la red de aquí a 2, 5, 10 y 15 años).
- Debe ser flexible. Por ejemplo, el día de mañana pueden haber nuevos servicios o expandir la cobertura hacia otras ciudades.
- Debe ser simple y entendible, es decir, que evite complicar las cosas.
- Debe armarse con las mejores prácticas.
- Debe separar Infraestructura de clientes (importante).
Recomendaciones para empezar a hacer el plan de Direccionamiento IPv6.
1) El principal consejo y uno de los más básicos es manipular los bloques por nibbles, en pocas palabras, por cada carácter de la dirección IPv6.
¿Cómo quedaría visualmente el nuevo prefijo 3FFF::/20?
Como se observa en la siguiente imagen, debido a que el prefijo es un /20, los 5 primeros nibbles son fijos y todos los caracteres en “X” son los modificables:
2) Mapear los nibble para una función
Una práctica habitual es mapear un nibble o un grupo de nibbles a “algo”, siendo ese “algo” una función, un país, un servicio, tipo de clientes, entre otros.
Con el siguiente gráfico se detalla lo antes mencionado:
Para ISP:
Para Usuario Final (EU):
Importante: recordemos que los últimos 64 bits (C5, C6, C7 y C8) usualmente son asignados por el proceso de autoconfiguración y/o manualmente por el administrador.
Nota: Estos ejemplos son recomendaciones y muestran una de las tantas formas para realizar un plan de direccionamiento IPv6 dentro de una red.
Ejemplo práctico de un Plan de Direccionamiento IPv6:
Aquí te dejamos un par de ejemplos de un plan de direccionamiento utilizando el nuevo prefijo 3FFF::/20.
Nota: Estos ejemplos son recomendaciones y muestran una de las tantas formas para realizar un plan de direccionamiento IPv6 dentro de una red.Plan de Direccionamiento IPv6 para un ISP:
Para este escenario se ha considerado un ISP que opera en 3 países y 3 ciudades en cada país. Por lo que, utilizando la nomenclatura del ejemplo anterior, se han colocado valores y reemplazado los caracteres, de acuerdo con la categoría que representan, según se observa en la siguiente tabla:
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
miércoles, 23 de julio de 2025
Entrar a rommon en un Switch Cisco desde una laptop mac
Problema
Deseo entrar un rommon en un SW Cisco estando conectado vía consola. Los break sequence que intento ninguno sirve, incluso luego de probar los que están aquí https://blog.acostasite.com/2009/10/secuencia-de-escape-break-sequence.html:
NO me funcionó
Desde la MAC no me funcionó dejar la barra espaciadora 15 segundo en el arranque del equipo, ni a 9600 ni a 1200 baudios. No me sirvió crtl-A + crtl-B, ni el backspace.
SI me funcionó:
Utilizar Shift+CTRL+C durante los primeros segundos de encendido del Switch Cisco (en mi caso Cisco 4948)
Otro post:
https://blog.acostasite.com/2021/04/como-conectarse-via-consola-un-router.html
Espero te ayude.
sábado, 5 de julio de 2025
martes, 10 de junio de 2025
7 desafíos que enfrentó IPv6 y cómo fueron resueltos
¿Alguna vez pensaste que IPv6 no lograría despegar realmente? Si tu respuesta es “sí”, este blog es para ti.
En los últimos 20 años IPv6 pasó por muchos obstáculos que hicieron dudar a más de uno sobre su futuro. Desde el principio tuvo que enfrentar desafíos técnicos importantes: no era compatible con IPv4, muchos equipos antiguos no lo soportaban y, como suele pasar, hubo bastante resistencia al cambio por parte de operadores y empresas. A esto se sumaron varios mitos —como que era demasiado complejo o poco seguro— que también jugaron en su contra.
Pero el tiempo y la tecnología hicieron lo suyo. Gracias a herramientas de transición, mejoras en el enrutamiento y el desarrollo de hardware más preparado, IPv6 no solo demostró que puede escalar (¡estamos hablando de 340 undecillones de direcciones disponibles!), sino que también es más eficiente y seguro que el viejo IPv4.
Hoy, IPv6 ya no es una promesa: es una realidad. Está detrás del 5G, del futuro 6G, del Internet de las Cosas a gran escala y de la nube hiperconectada. Y además, soluciona problemas que arrastramos hace años, como la falta de direcciones y la fragmentación de las redes.
En este artículo vamos a desarmar algunos de los mitos más comunes —como que IPv6 baja el rendimiento o que no se lleva bien con sistemas antiguos— y vamos a mostrarte con datos y ejemplos reales por qué migrar a IPv6 no solo es posible: es necesario si querés que tu red esté preparada para lo que viene.
1. Mejora en la conmutación de paquetes a nivel de hardware
En los últimos 15 años los circuitos integrados de aplicación específica (ASICs) para redes han pasado de un soporte marginal a una implementación nativa y optimizada de IPv6. Antes de 2010, el procesamiento de IPv6 dependía de CPUs generales, generando alta latencia y bajo rendimiento. Entre 2010-2015, fabricantes como Cisco y Broadcom integraron tablas de forwarding IPv6 en hardware (TCAM), soporte para NDP/ICMPv6 y lookup eficiente en chips como el Cisco Nexus 7000 o Broadcom StrataXGS. Para 2015-2020, los ASICs alcanzaron madurez con tablas de routing escalables, offloading de extensiones IPv6 (headers, tunneling) e integración con SDN/NFV, ejemplificado por el Broadcom Tomahawk y Cisco Silicon One.
Desde 2020, IPv6 es prioritario en diseños de ASICs, con capacidades avanzadas como: Segment Routing IPv6 (SRv6) acelerado, seguridad nativa (IPsec en hardware), y optimización para IoT/5G. Chips como el Broadcom Jericho2 (2020), Marvell Octeon 10 (2022) e Intel Tofino 3 (2023) soportan millones de rutas IPv6 y procesamiento programable (P4), consolidando IPv6 como estándar en redes modernas. Esta evolución refleja la transición de IPv6 de un complemento software a un componente crítico en el hardware de red.
Período Soporte IPv6 en ASICs Limitaciones
Pre-2010 Mínimo o por software Alto costo de CPU, baja eficiencia
2010-2015 Primeras implementaciones en TCAM/ASICs Tablas IPv6 limitadas
2015-2020 Madurez en switches/routers empresariales
2020-Actualidad IPv6 nativo, optimizado para cloud/5G/SRv6
Comparativa Resumida sobre evolución de las ASICs
2. El dilema del huevo y la gallina en IPv6
El dilema del huevo y la gallina en el contexto de IPv6 se refiere a la paradoja de cómo impulsar la adopción de esta nueva versión del Protocolo de Internet. Es como si nadie quisiera comprar un nuevo tipo de teléfono porque no hay apps para él, pero los desarrolladores no crean apps porque casi nadie tiene ese teléfono.
Por un lado, los proveedores de contenido (como plataformas de streaming y sitios web) necesitan que haya suficientes usuarios que utilicen IPv6 para justificar la inversión en infraestructura y optimización para este protocolo. Por otro lado, los usuarios finales requieren acceso a contenido disponible a través de IPv6 para motivarse a hacer la transición desde IPv4. Sin una base sólida de ambos lados, se crea un ciclo vicioso donde la falta de usuarios limita el contenido disponible y la escasez de contenido desincentiva a los usuarios a adoptar IPv6.
La realidad en 2025 es muy distinta: una larga lista de las principales CDNs (redes de distribución de contenidos) y sitios web a nivel mundial ya soportan IPv6 desde hace varios años. Como resultado, los clientes que aún no implementan IPv6 suelen experimentar un rendimiento de conectividad ligeramente inferior en comparación con aquellos que sí lo utilizan.
Un hecho no menor que ha impulsado considerablemente la adopción de IPv6 entre los proveedores es el impacto del mundo de los videojuegos y la comunidad gamer. Resulta ampliamente conocido el fuerte respaldo que las principales consolas han brindado a IPv6, como es el caso de Xbox (desde 2013) y PlayStation (desde 2020).
CDN/Sitio Web Año de Adopción IPv6
Cloudflare 2011 Primer CDN en soportar IPv6 globalmente
Google (Búsqueda, YouTube) 2012 Habilitación progresiva
Facebook/Instagram 2013 Adopción completa en 2014
Wikipedia 2013 Uno de los primeros sitios en adoptar
Akamai 2014 Soporte gradual por región
Netflix 2015 Prioriza IPv6 para reducir latencia
Amazon CloudFront 2016 Soporte completo en edge locations
Apple (App Store) 2016 Requisito obligatorio para apps iOS
Microsoft Azure CDN 2017
Fastly 2018 Soporte nativo en toda su red
Tabla de adopción IPv6 en contenido .Fuente: Deepseek (Mayo 2025)
3. Enrutamiento con Prefix Delegation
Una situación muy interesante, que ocurrió hace 10-15 años, era la dificultad que muchos proveedores de servicios de Internet (ISPs) enfrentaban al implementar DHCPv6-PD (Prefix Delegation). Era común que surgieran problemas de enrutamiento: por ejemplo, un host o una red remota (CPE) podía recibir correctamente un prefijo IPv6, pero las rutas necesarias para alcanzar ese prefijo no estaban configuradas en el ISP. Era como si el cartero supiera tu dirección, pero no tuviera un mapa para encontrar cómo llegar a tu casa.
Hoy os ISPs han actualizado sus infraestructuras para manejar automáticamente el enrutamiento de los prefijos delegados, mientras que los routers modernos (tanto domésticos como empresariales) incluyen soporte robusto para DHCPv6-PD. Ahora, cuando un cliente recibe su bloque IPv6, el ISP inmediatamente propaga las rutas necesarias, y el router local configura automáticamente las subredes internas. Esto ha hecho que la delegación de prefijos IPv6 sea tan confiable como el DHCP tradicional de IPv4, eliminando uno de los dolores de cabeza iniciales de la transición.
Aspecto Hace 10 Años Actualidad (2024)
Asignación de prefijo DHCPv6-PD sin rutas en el core DHCPv6-PD + auto-anuncio BGP/IGP
Comportamiento del CPE Recibía el prefijo o no configuraba rutas Configura automáticamente LAN + rutas
Conectividad Solo tráfico saliente (entrante perdido) Full bidireccional (entrante/saliente)
Soluciones temporales NAT66, túneles manuales, redistribute connected en el CPE Enrutamiento nativo sin hacks
Comparativa: 2014 vs. 2024
4. Formación y aprendizaje colectivo
Hace dos décadas, adoptar IPv6 era un desafío técnico y educativo. La documentación resultaba escasa, dispersa y a menudo demasiado técnica, dejando a muchos administradores de redes aprendiendo mediante ensayo y error. Los primeros cursos disponibles se limitaban principalmente a especificaciones teóricas del protocolo, con poca orientación práctica sobre implementación real en redes operativas. Esta falta de recursos formativos de calidad ralentizó inicialmente la adopción de IPv6, especialmente en entornos empresariales y operadores pequeños.
Hoy en día, diferentes organizaciones, incluyendo LACNIC, han liderado un esfuerzo educativo masivo para reducir las barreras de entrada a IPv6. Ejemplos de esto son el Campus de LACNIC, con cursos que van desde nivel básico hasta avanzado, publicaciones en blogs, videos, podcasts, y otros recursos didácticos.
Además, iniciativas como LACNOG (y otros NOGs regionales) y los ya clásicos talleres prácticos de IPv6 de LACNIC han contribuido a crear espacios de formación y discusión técnica sobre la implementación de IPv6 en redes reales.
A seu vezmuchas empresas privadas han incluido IPv6 como tema obligatorio en sus programas de formación y certificación, tanto en cursos como en exámenes.
La comunidad técnica tampoco se ha quedado atrás: cientos de personas, desde estudiantes hasta ingenieros de redes senior, comparten regularmente recursos en diferentes redes sociales, generando artículos, videos, blogs y notas técnicas que ayudan a cerrar las brechas de conocimiento y a fortalecer el aprendizaje colectivo sobre IPv6.
5. Compatibilidad con aplicaciones
Veinte años atrás, el soporte IPv6 en aplicaciones era una suerte de lotería. Si existía IPv4 e IPv6 en la red era aún más complicado. Por ejemplo, en una red IPv6 Only si la app usaba direcciones IPv4 literales lógicamente iba a fallar. Muchos desarrolladores asumían que en todas las redes había IPv4 de facto. También en los sistemas operativos existían bibliotecas obsoletas que no soportaban el nuevo protocolo. Esto creaba una situación absurda: incluso cuando un usuario o empresa tenía una red IPv6 perfectamente configurada, sus herramientas cotidianas -como lector de correo electrónico- simplemente dejaban de funcionar.
Hoy la situación ha dado un vuelco radical. Grandes plataformas como la App Store de Apple (desde 2016) y Google Play exigen que las aplicaciones nuevas sean IPv6-compatibles (a pesar de esta última no lo coloca de manera explícita) como requisito obligatorio. Adicionalmente mecanismos como Happy Eyeballs apoyan la transición a IPv6 a nivel de software de manera transparente. Las principales bibliotecas de programación (como las de Python, Java y Node.js) incluyen soporte nativo para IPv6 desde hace años, eliminando excusas para los desarrolladores. Empresas como Microsoft, Google y Cloudflare han liderado este cambio, demostrando que el rendimiento en IPv6 puede ser incluso mejor que en IPv4. Lo que antes era un dolor de cabeza ahora es una ventaja competitiva: las aplicaciones que adoptan IPv6 primero disfrutan de menor latencia, mejor seguridad y acceso a la próxima generación de usuarios conectados.
6. Fragmentación y MTU (Maximum Transmission Unit)
A diferencia de IPv4, IPv6 elimina la fragmentación en los routers intermedios, lo que significa que los paquetes deben respetar el MTU (Maximum Transmission Unit) de toda la ruta desde el origen hasta el destino. Esta decisión de diseño mejora la eficiencia general de la red, pero en sus primeros años (hace 10, 15 o 20 años), generó bastantes dolores de cabeza: muchos dispositivos implementaban de forma incorrecta el mecanismo de Path MTU Discovery (PMTUD), lo que provocaba pérdida de conectividad en situaciones comunes.
En particular, routers antiguos y sistemas operativos sin actualizar no sabían manejar bien los mensajes ICMPv6 “Packet Too Big”, que son esenciales para que el emisor ajuste el tamaño de los paquetes. Como resultado, la comunicación se rompía en redes donde el MTU era más bajo de lo esperado.
Actualmentelos sistemas operativos modernos y los equipos de red actuales ya manejan correctamente el PMTUD, respondiendo y ajustando dinámicamente el tamaño de los paquetes en función de los mensajes ICMPv6. Esto ha hecho que estos problemas sean mucho menos frecuentes y que la red funcione de manera más estable y eficiente bajo IPv6.
7. El envío de DNS vía RA
En los primeros años de IPv6 (hasta aproximadamente 2010), configurar servidores DNS en los clientes de red era un proceso más complejo e indirecto. Los routers enviaban mensajes Router Advertisement (RA) con el flag O (Other Configuration) activado, lo que obligaba a los clientes a hacer una solicitud adicional mediante DHCPv6 para obtener la información de los servidores DNS. Este enfoque, heredado del mundo IPv4, traía consigo varios inconvenientes: mayor latencia en la configuración, dependencia de un servicio adicional y mayor complejidad para redes simples o dispositivos con recursos limitados, como muchos equipos IoT.
Esta limitación se resolvió con la introducción de la opción RDNSS (Recursive DNS Server) dentro de los propios mensajes RA de ICMPv6, formalizada en el RFC 6106 (2010). A partir de entonces, los routers pudieron anunciar directamente los servidores DNS a los clientes, simplificando drásticamente la autoconfiguración.
Aunque al principio hubo cierta resistencia por parte de fabricantes de sistemas operativos y routers, entre 2015 y 2017 el soporte para RDNSS se volvió común: Windows 10, Linux (con systemd-networkd), iOS 9+ y la mayoría de los routers empresariales ya lo implementaban.
Hoy esta funcionalidad está prácticamente universalizada en equipos modernos y se considera una mejor práctica en redes IPv6, eliminando la necesidad de usar DHCPv6 solo para DNS y habilitando despliegues mucho más simples, tipo “plug and play”.
Conclusiones
En retrospectiva, tras más de dos décadas de evolución, IPv6 ha superado obstáculos que en su momento parecían insalvables, pasando de ser un protocolo casi teórico a convertirse en la columna vertebral de la Internet moderna.
Los desafíos técnicos que antes generaban incertidumbre hoy cuentan con soluciones estandarizadas, eficientes y ampliamente adoptadas, fruto de la colaboración entre la industria y organismos como el IETF. Mitos como su supuesta “complejidad” o “incompatibilidad” han sido superados por evidencias concretas de mejor rendimiento, mayor seguridad y capacidad de escalado real.
IPv6 es el presente. Con casi el 50% del tráfico global circulando sobre IPv6 (y cerca del 40% en América Latina y el Caribe), soporte nativo en CDNs, sistemas operativos y aplicaciones, y un papel fundamental en tecnologías como 5G, IoT y cloud hiperconectada, la transición total es solo cuestión de tiempo. Seguir postergando su adopción no solo significa perder ventajas técnicas: es avanzar hacia la obsolescencia.
La lección es clara: adoptar IPv6 es un imperativo estratégico. No implementarlo es correr el riesgo de quedar aislado en una Internet que ya ha dado el siguiente paso.
Referencias:
RFC 6106: https://datatracker.ietf.org/doc/html/rfc6106
Centro de estadísticas de LACNIC: https://stats.labs.lacnic.net/IPv6/graph-access.html
https://developer.apple.com/support/downloads/terms/app-review-guidelines/App-Review-Guidelines-20250430-English-UK.pdf
martes, 18 de marzo de 2025
Se viene esta palabra: noiafobia
noiafobia = No Inteligencia Artificial Fobia
o
noaifobia = No Artificial Intelligence Fobia
martes, 28 de enero de 2025
¿Qué historia hay detrás de las famosas máscaras de red?
Introducción
¿Recuerdas cuando estabas aprendiendo de máscaras de red? Seguro llegaste a pensar: “no sirven para nada”, “no las voy a necesitar”, “¿por qué inventaron esta locura?”. Además de sacarte una sonrisa espero convencerte de la enorme importancia que tienen en el gigantesco ecosistema de Internet.
Objetivo
Este blog post resume la historia y los hitos relacionados detrás de los conceptos de máscara de red en el mundo de IPv4. Comenzamos la historia en un mundo donde no existían las clases (plano-flat), pasamos por un mundo classful y finalizamos en un Internet totalmente classless (CIDR). La información se basa en extractos de los RFC 790, 1338 y 1519, junto con hilos de correo electrónico de la lista de correo ‘Internet-history’.
¿Sabes lo que es la máscara de red?
Asumo que si llegaste a este documento si lo sabes :-) pero aquí va un mini concepto: una máscara de red se utiliza para ubicar y dividir un espacio de dirección de red y una dirección de host, en otras palabras, indica al sistema cuál es el esquema de particionamiento de subred.
¿Cuál es el propósito de la máscara de red?
Enrutamiento: Los enrutadores utilizan la máscara de red para determinar la porción de red y encaminar correctamente los paquetes.
Subnetting: Las máscaras de red se utilizan para crear redes más chicas.
Aggregación: Las máscaras de red permiten la creación de prefijos más grandes.
¿Siempre han existido las máscaras de red?
No, muy interesantemente no siempre existió la máscara de red, al comienzo las redes IP eran planas (flat) y siempre asumían 8 bits para la red y 24 bits para el host. En otras palabras, el primer octeto era la red, y los 3 octetos restantes corresponden al host. Otro aspecto llamativo es que hace muchos años también recibía el nombre de bitmask o solo mask (aún utilizado ampliamente).
Lo anterior conlleva a que no siempre existieron las clases (A, B, C, D)
Las clases no existieron hasta la aparición del RFC (septiembre 1981) de Jon Postel, es decir, incluso era una época antes de classless y classful.
La introducción del sistema classful fue impulsada por la necesidad de acomodar diferentes tamaños de red, ya que el ID de red original de 8 bits era insuficiente (256 redes). El sistema classful fue un intento de abordar las limitaciones de un espacio de direcciones plano, aunque este también tenía limitaciones de escalabilidad. En el mundo de las clases la máscara de red era implícita.
Las clases tampoco solucionaron todo
Si bien el sistema classful fue una mejora sobre el diseño original (plano), no era eficiente. Los tamaños fijos de los espacios de red y hosts de las direcciones IP llevaron al agotamiento del espacio de direcciones, especialmente con el creciente número de redes que eran más grandes que una Clase C, pero más pequeñas que una Clase B. Lo anterior llevó al desarrollo del enrutamiento Inter-Dominio Sin Clases (Classless Interdomain Routing – CIDR), que utiliza máscaras de subred de longitud variable (Variable Length Subnet Mask – VLSM).
Extracto del RFC 790
¿Sabías que no siempre la máscara se escribió con bits continuos encendidos de izquierda a derecha?
Al comienzo en la máscara de red no debía “encenderse” bit a bit de izquierda a derecha, es decir, máscaras como: 255.255.192.128 era completamente válidas. Esta configuración era aceptada por routers (IMPs -los primeros routers-) y diferentes sistemas operativos, entre ellos los BSDs y SunOSs antiguos. Es decir, hasta comienzos de los 90’s aún era posible tener máscaras de red de bits no continuos.
¿Por qué se decidió que los bits luego fueran obligatoriamente encendidos de izquierda a derecha?
Existieron varias razones, la principal tiene que ver con enrutamiento y el famoso concepto “longest match” que conocemos donde el router selecciona la ruta cuya máscara de subred sea la más larga que coincida con la dirección de destino del paquete. Es decir, si los bits no son continuos se crea una complejidad computacional muy alta. En resumen: eficiencia.
Desde esa época ya se agotaban direcciones IPv4
El agotamiento de recursos IPv4 no es algo nuevo, incluso en la primera sección del RFC 1338 en su numeral uno hace referencia al agotamiento de la Clase B indicando que la Clase C es demasiado pequeña para muchas organizaciones, y la Clase B es demasiado grande. Esto ocasionó una presión sobre el espacio de direcciones Clase B, agotando la misma. Y no solo eso, el mismo RFC en el numeral 3 cita textualmente: “Eventual exhaustion of the 32-bit IP address space” (1992).
CIDR aborda las soluciones de ayer, que se convirtieron en los problemas de ese momento
Al momento de crear las clases se crearon más redes lo que conlleva a más prefijos y a su vez mayor consumo de memoria y CPU. Por ello en septiembre de 1993 en el RFC 1519 apareció el concepto de CIDR, trayendo consigo soluciones a algunas situaciones, entre ellas, poder hacer supernetting (es decir, poder apagar bits de derecha a izquierda) e intentar reducir la cantidad de prefijos de red. Es importante destacar que el RFC 1338 también mantuvo conceptos similares.
Finalmente, la notación de prefijo (/nn) también aparece gracias a CIDR lo que se hace posible una vez más gracias a la continuidad de los bits encendidos y apagados de la máscara de red.
En resumen, el objetivo de CIDR era enlentecer el crecimiento de las tablas de enrutamiento y buscar ser más eficientes en la utilización del espacio de direcciones IP.
Timeline
Conclusiones
El concepto de máscara de red ha evolucionado notablemente desde su origen, desde su no-existencia en un esquema plano (flat), luego rígido a un modelo flexible con CIDR. Inicialmente, las redes classful y las máscaras discontinuas generaban ineficiencia y problemas de escalabilidad a medida que Internet crecía.
Un cambio clave fue la exigencia de continuidad en los bits encendidos, lo que simplificó el proceso de selección de rutas y permitió a los routers operar más eficientemente.
Este documento informativo resalta los hitos clave y las motivaciones detrás de la evolución del direccionamiento IP y enfatiza la importancia de comprender el contexto histórico para apreciar plenamente la arquitectura actual de Internet.
Referencias
RFC https://datatracker.ietf.org/doc/html/rfc1338
RFC https://datatracker.ietf.org/doc/html/rfc1380
RFC https://datatracker.ietf.org/doc/html/rfc1519
RFC https://datatracker.ietf.org/doc/html/rfc790
Hilo de la lista de correo de ISOC “Internet History” llamado “The netmask”: https://elists.isoc.org/pipermail/internet-history/2025-January/010060.html
martes, 21 de enero de 2025
BGP Dynamic Capabilities / Capacidades Dinámicas en BGP
El video muestra el funcionamiento del concepto "BGP Dynamic Capabilities" donde dos peers BGP pueden comunicarse sus capacidades "on the fly" sin interrupción de la sesión. El demo fue contruido con FRR hablando BGP sobre IPv6 y utilizamos como demostración la capacidad extended-nexthop la cual no es anunciada en el mensaje Open inicial. Un video enriquecedor que demuestra una vez más la enorme flexibilidad del protocolo BGP
Suscribirse a:
Entradas (Atom)
-
Saludos, Lo primero que debemos de hacer para quitar el stacking entre los switches es desconectar los cables Stack que los unen.... Es buen...
-
Necesidad Contar con dos routers y una dirección IP en Standby (HSRP), donde ciertas redes origen enrutarlas por el Carrier A y otras redes ... -
Introduccion: En algunas ocasiones es necesario "bajar" o deshabilitar iptables en nuestro Linux, el procedimiento depende de...