Mostrando entradas con la etiqueta internet. Mostrar todas las entradas
Mostrando entradas con la etiqueta internet. Mostrar todas las entradas

domingo, 29 de diciembre de 2019

Retrospectiva sobre el crecimiento de IPv6 durante el 2019 en Latinoamerica y Caribe

Muy buenos días Lista, 
  Existe un refrán que estoy seguro todos conocen: “El hombre es un animal de costumbre”, por sexto diciembre consecutivo estamos entregando una retrospectiva sobre IPv6 en nuestra querida región.
  Costumbre es sinónimo de consuetudinario, es decir, estamos casi que rozando la ley en estos mensajes, espero no se me olvide el año que viene !


  Y bueno, 6to año, hablando de IPv6 tengo que intentar explayarme.


  De igual manera como he hecho en otras oportunidades, comencemos repasando el concepto de retrospectiva [1]


“Retrospectiva (del latín: retrospectare) es una enumeración y
celebración de eventos ya ocurridos, y normalmente organizada y
presentada al final del año, en algún medio de difusión (generalmente
televisión o radio), aunque también puede abarcar un período mayor del
anual.”


  Y les aseguro que al leer este concepto, no me viene a la cabeza ningún otro mejor adjetivo que pueda enmarcar lo que deseamos expresar aquí.


  Por ser 6to año y celebrando IPv6 cubriremos los TOP 6 países de nuestra región.


  Voy a indicar los 6 pasos que tomé:
  1. Ubicar los TOP 6 países de nuestra región es cada vez más sencillo, hoy en día vamos a: https://stats.labs.lacnic.net/IPv6/ipv6ranking.html 
  2. Hacemos click sobre el checkbox LACNIC
  3. Repasamos 1 a 1 cada país obtenido en el paso anterior
  4. En algunas oportunidades hacemos click en “Per ASN” correspondiente al país
  5. Listo !, a escribir


 Los TOP 6 países con su respectivo % de penetración de IPv6 en el usuario final son (para comienzos de diciembre 2019):
1 UY 38.27
2 GF 35.61
3 MX 31.96
4 BR 28.69
5 TT 20.26
6 PE 18.53



  Hablemos de cada caso:
  1. Uruguay (UY), el segundo país más chico de Sur América (luego de Surinam) dice muy presente cuando se trata de penetración de IPv6 y velocidad a Internet, es líder en ambos rubros en nuestra región, casi 40 de cada 100 uruguayos ya cuentan con IPv6 -y la velocidad promedio de bajada en el móvil es sobre los 20 Mbps-. Un gran aplauso.


  1. Guyana Francesa (GF), casa de “Le Centre Spatial Guyanais” conocido como la  Guiana Space Centre donde muchos países Europeos utilizan este centro espacial para sus lanzamientos, y algo similar hicieron con IPv6, le pusieron un cohete ! . Nuestras gráficas indican que comenzó su despliegue a comienzos de Abril 2019 y a las dos semanas tenían 20% de IPv6 y a las 5 semanas cerca de 35.61%, mientras escribimos estas líneas sigue creciendo. Nuestras felicitaciones.


  1. México (MX), conocido por muchas cosas pero entre otras por su celebración del día de los muertos, sin embargo le están diciendo al mundo que en IPv6 están muy vivos :-)   , ya habían comenzando 2019 con 24% de penetración de IPv6 y en el transcurso del 2019 tuvieron un crecimiento superior al 30%. Por cierto, también son el exportador más grande del mundo en cerveza y parece que quieren exportar IPv6.  Vamos arriba México


  1. Brasil (BR), haciendo honor a su slogan (motto) “Ordem e Progresso” (order and progress) han hecho precisamente lo mismo con IPv6. Durante el 2019 Brasil incrementó en un 10% su penetración de IPv6 llegando a 30.22%. Nada mal para el país más grande la región y 5to en el mundo. Nuestros respetos.


  1. Trinidad y Tobago (TT), cuna del instrumento musical “Steel Pan” (tambores metálicos), digno representante caribeño en despliegue IPv6 implementa el protocolo con buen ritmo para no quedarse atrás. TT se posiciona en 5ta posición en la región ofreciendo IPv6 a 1 Trinitario cada 5 personas, creo que quieren correr a la velocidad de Hasely Crawford (el Usain Bolt Trinitario en 1976)


  1. Perú (PE), lo primero que se me viene a la cabeza es su gastronomía, Machu Picchu y los Inca, pero solo quiero decir que su despliegue IPv6 es casi tan alto como su famoso lago Titicaca, el más alto del mundo. Perú desde hace varios años es icono de despliegue de IPv6 en la región y nos contenta mucho verlos aún como líderes en este rubro. Para el momento que se escribe estas líneas, el país cuenta con un poco más de 18% de penetración de IPv6.  Que continúen el despliegue con un Pisco sour :-)


¿Y el promedio de Latam?
Ya hace un año explicamos que anteriormente en LACNIC publicabamos un promedio simple (media aritmética) del promedio IPv6 en nuestra región. Hoy en día estamos publicando una *media aritmética ponderada* en base a la población de los países, población de LAC y grado de penetración de IPv6 en el país, esto nos lleva a un valor más real de usuarios de Internet con IPv6 en nuestra región.  
La penetración de IPv6 en el usuario final en LATAM está en 19.50%, un número nada mal pero aún por debajo de la media mundial (29%) [2]. Recordemos que país que no implemente IPv6 corre el riesgo de quedarse aislado. Vamos LAC !!



¿Alguna mala noticia en el 2019?
Lastimosamente tenemos una pero mejor que el año pasado.
Una de las mediciones que hacemos en LACNIC es ubicar sitios Web con ccTLDs de nuestra región e identificar si tienen IPv6, posteriormente estudiamos si estos sitios apuntan a una dirección IP asignada por LACNIC [7].
En el 2017 teníamos que el 33.9% de estos sitios con IPv6 apuntaban a direcciones asignadas por LACNIC. Para el diciembre del 2018 solo 19%. Interesantemente este 2019 volvimos a 33.2% de sitios Web en LAC que apuntan a direcciones IP asignadas por LACNIC.
Esperemos que para el 2020 este valor aumente, si se puede !.




Pronóstico para el año que viene.
Realizar pronósticos siempre ha sido algo muy complicado, creo que nosotros como personas de ciencia nos basamos más en hechos reales, en números. Sin embargo equivocarse con IPv6 hasta cierto punto no es difícil, IPv6 seguirá creciendo, el despliegue aumentará en nuestra región. Un hecho que pienso que está ocurriendo es que ya los clientes están atentos de saber si el ISP soporta IPv6, en caso negativo buscan otro ISP y listo, ahora todos los países ya cuentan con proveedores con IPv6. El tema de los túneles ya viene en bajada desde hace muchos años, habiendo dicho eso comienza una etapa verdadera de pérdida de clientes si el proveedor no ofrece IPv6. Una vez más veremos crecimiento en redes IPv6 Only tales como Data Centers.



 Reciban un fuerte abrazo,




Alejandro Acosta,
@ITandNetworking





jueves, 10 de octubre de 2019

Configurando una sesión BGP entre dos loopbacks con IPv6 - ebgp multihop y captura de wireshark

En el video se muestra como configurar una sesión BGP entre dos enrutadores Cisco IOS. Se realiza con ebgp multihop y se muestra captura de paquetes con Wireshark


martes, 30 de abril de 2019

Como verificar si un sitio Web se encuentra bloqueado

Hola,
  Si en google por ejemplo buscamos "como revisar si un sitio web esta bloqueado" será difícil  conseguir información de como revisar nosotros mismos, los resultados serán principalmente sitios Web que pueden abrir la página Web por tí, mostrarte desde otros sitio si puede conectarse, algún plugin que puedas instalar. En estás páginas se puede revisar si un sitio está arriba o no: https://www.blocked.org.uk/check y https://downforeveryoneorjustme.com/

   NOTA: Este post es básicamente como podemos revisar nosotros mismos un bloqueo. Estamos hablando de bloqueos por parte de un ISP/país, no de bloqueos en el firewall en una empresa o compañía. Se aceptan sugerencias y quejas.., comentarios están abiertos al final del documento

Introducción:
  Como algunos de ustedes saben, existen muchas manera de bloquear sitios Web, principalmente los bloqueos ocurren de 4 maneras:
1) DNS
2) Routing
3) Capa 4 (bloqueo de puertos TCP/UDP a ciertos destinos)
4) Capa 7 (bloqueo de por ejemplo la URL/dominio)

  Ahora bien, antes de continuar quiero dejar claro mi posición en cuanto a los bloqueos en Internet: ME PARECEN MUY MALA IDEA y no trae nada bueno al país/ISP..., y en el supuesto que traíga una cosa buena, trae 10 cosas malas. Tengo algunas cosas plasmadas en este post: https://blog.acostasite.com/2014/10/la-mala-idea-de-bloquear-internet.html

Pasos para revisar un bloqueo de un sitio Web:
  Ahora bien, en el supuesto que queramos saber si algún sitio se encuentra bloqueado, podemos seguir estos pasos (preferiblemente Linux y/o MAC):

1) Revisar si el bloqueo es por DNS. ¿Cómo lo hacemos?
   Podemos usar dos herramientas de resolución DNS. Para este ejemplo utilizaremos dig y/o nslookup.


.- Utilizando dig
MacBook-Pro-2:tmp$ dig +short www.example.com
172.XX.YY.39

.- Utilizando nslookup
MacBook-Pro-2:tmp$ nslookup www.example.com
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: www.example.com

Address: 172.XX.YY.39

¿Qué hay que revisar de la salida?
Básicamente con el comando, le pedimos a dig que muestre de manera resumida, que direcciones IP resuelve www.example.com. En este sentido 172.XX.YY.39 será el IP al cual nuestra computadora se va a conectar. Lo importante aquí es identificar si 172.XX.YY.39 corresponde al IP destino que nos queremos conectar (si, ciertamente pueden resolver direcciones diferentes y eso, pero si sabes eso no necesitas leer este documento :) !! )  Muchas veces algunos ISPs cambian la resolución de un dominio y no verías el IP correcto sino otra al cual es imposible conectarse (por ejemplo, 127.0.0.1)


2) Routing

  Para revisar routing principalmente utilizaremos traceroute (tracert en Windows)

  La idea es en lineas generales ver si podemos alcanzar el destino desde nuestra computadora:


Utilizando traceroute:


MacBook-Pro-2:tmp$ traceroute -n 8.8.8.8  (sustituye 8.8.8.8 por el dominio o el IP obtenido en el paso previo)
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
 1  192.168.1.1  1.724 ms  1.030 ms  1.376 ms
 2  190.XX.XX.1  28.969 ms *  35.939 ms
 3  172.YY.13.33  27.988 ms  27.379 ms  29.267 ms
 4  * * *
 5  10.XX.1.105  29.229 ms 28.628 ms 28.303 ms
 6  10.XX.1.1  38.332 ms  26.855 ms 28.605 ms
 7  200.XX.XX.177  61.560 ms  62.466 ms  68.661 ms
 8  72.NN.NN.84  62.411 ms  62.523 ms 62.188 ms
 9  108.170.253.17  62.537 ms  63.011 ms 63.182 ms
10  108.170.226.13  63.588 ms 65.335 ms 62.301 ms

11  8.8.8.8  62.329 ms  63.023 ms  62.176 ms

¿Qué hay que revisar de la salida?

  Como se puede ver en el traceroute de arriba, se llegó satisfactoriamente al destino.
  En el caso de ver algún "!" seguido por una letra, es mala noticia. Por ejemplo ver esto en el traceroute significa que hay algo mal, quizás el ISP bloqueó las direcciones IP destino de alguna manera.

  Errores comunes (tomados de la página del manual de traceroute):


 !H, !N, or !P (host, network or protocol unreachable)
  !S (source route failed)
  !U or !W (destination network/host unknown) 
 !I (source host is isolated)
 !A (communication with destination network administratively prohibited)
 !Z (communication with destination host administratively prohibited)
 !Q (for this ToS the destination network is unreachable), 
 !T (for this ToS the destination host is unreachable), 
 !X (communication administratively prohibited), 
 !V (host precedence violation), 
 !C (precedence cutoff in effect), or 
 ! (ICMP unreachable code ). 

Extra:
  Otra herramienta que recomiendo para revisar este punto es MTR  (My traceroute) ; https://es.wikipedia.org/wiki/MTR_(software).., es una combinación de ping y trace. MUY buena.


3) Capa 4 (bloqueo de puertos a ciertos destinos)
  Para revisar bloqueos de capa 4, principalmente la idea es revisar conectividad a nivel de puertos (TCP) desde tu computadora al destino.
  La herramienta más sencilla para revisar esto es telnet, la intención al ejecutarlo es chequear que efectivamente "se conectó" nuestra computadora al destino.

Utilizando telnet:
Ejemplo 1: (conecta¡ándose al puerto http)

MacBook-Pro-2:tmp$ telnet www.example.com 80  -- 80 quiere decir el puerto destino
Trying 199.NN.NN.100...
Connected to www.example.com. --- esto es lo que hay que revisar

Escape character is '^]'.


Ejemplo 1: (conectándose al puerto https)
MacBook-Pro-2:tmp$ telnet www.example.com 443  -- 443 quiere decir el puerto destino
Trying 199.NN.NN.100...

Connected to www.example.com.   --- esto es lo que hay que revisar
Escape character is '^]'.


Cuando el destino se encuentra bloqueado a nivel de 4 veríamos algo así:

MacBook-Pro-2:tmp$ telnet www.example.com 80
Trying 199.XX.XX.100...
telnet: connect to address 199.XX.NN.100: Operation timed out

telnet: Unable to connect to remote host

Depende el tipo de bloqueo, el telnet puede ser rechazado muy rápido (reject *), quizás el telnet solo dure mucho hasta que haga timeout.

* tu computadora recibe un icmp error desde el dispositivo que se encuentra bloqueando

4) Capa 7 (bloqueo de por ejemplo la URL/dominio)
  Revisar capa 7 viene a ser cuando el ISP es capaz de identificar el contenido de paquetes HTTP y chequear por el texto del dominio bloqueado dentro de él, es decir: el ISP quiere bloquear www.example.com, algunos dispositivos dentro del ISP son capaces de revisar a nivel de capa de aplicación (capa 7) el fqdn www.example.com, y allí tomar la decisión: bloquear o no.

  Para lo anterior, recomiendo utilizar curl o wget. Dejaré solo el ejemplo con curl:

Utilizando curl (en hacia un destino bloqueado)


MacBook-Pro-2:tmp$ curl -v https://www.example.com
* Rebuilt URL to: https://www. example.com/
*   Trying 172.NN.NN.39...
* TCP_NODELAY set
* Connected to www.example.com (172.NN.NN.39) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443 
* stopped the pause stream!
* Closing connection 0

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443 


¿Qué hay que revisar de la salida?
   No hay que asustarse con la salida, aquí hay revisar que la negociación SSL/TLS no pudo completarse, esto lo podemos apreciar al conseguir que el texto *ERROR* se ve en la salida.
   Nota: Cuando la salida es satisfactoria, veremos código html



Conclusión:
  Existen MUCHAS manera de bloquear acceso a sitios en Internet, incluso en algunas oportunidades puede usarse una combinación de varias maneras para lograr un bloqueo.

  Se que el post puede ser mucho más amplio y faltaron cosas por cubrir, sin embargo a su vez espero que él mismo sea visto como una introducción.

  El bloqueo de sitios Web en Internet no trae beneficios.









miércoles, 6 de febrero de 2019

DNS: Bloquear o no bloquear las direcciones IPv6 6to4


Introducción
  El servicio de DNS es sin duda alguna uno de los pilares de Internet, sin DNS el Internet no sería ni remotamente como lo conocemos hoy en día.
  DNS es el servicio que permite -entre otras funciones- convertir nombres de dominios a direcciones IP y viceversa.


Sobre el proyecto IPv6 Open Resolvers:
  Dentro de Lacnic, desde comienzos del año 2018 [1] estamos en la búsqueda de servidores DNS sobre IPv6 que son consideraciones “Open Resolvers” [2]

¿Que tiene que ver 6to4 con Open Resolvers y seguridad?
  Durante el tiempo que tiene este proyecto en funcionamiento hemos tenido la oportunidad de exponer el estudio y sus resultados [3] en sitios como DNS-OARC 28 , LACNIC 29 y NANOG 74. En esta última, recibimos muy buenos comentarios y quizás el más significativo fue el de George Wes donde él indicaba la existencia de muchos servidores DNS con direcciones IP 6to4 [4] las cuales utilizan direcciones IP de túneles automáticos dentro del prefijo 2002::/16.
  En base a lo anterior, decidimos profundizar en este concepto y estudiar con más detalle los resolvers con direcciones IPv6 6to4 y obtuvimos información muy interesante.

  Por ejemplo, el día 2 de Diciembre del 2018 estudiamos: 6248 servidores, de los cuales 61 estaban contenidos en el prefijo 2002::/16, y de aquí tuvimos 20 servidores abiertos, es decir, casi un 33%. Todos ellos potenciales para realizar diferentes ataques de DNS como de amplificación, cache poisoning, DDoS, DNS hijacking, entre otros.

  Aquí tenemos dos gráficos de lo arriba expuesto:






   Conclusión
   Primero, el problema per sé no es el 6to4, son los Open Resolvers. Segundo, como administrador de servidores DNS ustedes deben querer responder a la mayor cantidad de queries posibles de clientes válidos, nuestra recomendación no se ajusta solo a redes 6to4, sino básicamente la implementación de RLL (Response Rate Limit) a los queries según el origen, claro prestarle mayor atención a las provenientes del prefijo 2002::/16 no es mala idea.

Referencias


vivo v15 pro
beautiful Rohini escorts for you

martes, 10 de julio de 2018

Crear ruta IPv6 en MAC OS y revisar tabla de vecinos IPv6

Crear ruta:

  route add -inet6 -net 2000::/3 2001:XXX:XX:XX::1


Revisar tabla de vecinos IPv6:




  ndp -an

Video: Revisando la nueva características AddPaths-Limit en FRR. Una mejora al tradicional AddPath de BGP

  En el video recorremos y realizamos un Demo sobre el draft "Paths Limit for Multiple Paths in BGP ". Un documento que viene a se...