jueves, 14 de diciembre de 2017

Comprobado: Santa Claus SI tiene IPv6

Buenas noches,
 El día de hoy me he dado cuenta que Santa (Papa Noel) SI tiene IPv6, más específicamente tiene Doble Pila (IPv4 & IPv6). Lo anterior lo digo porque indiscutiblemente Santa le llega a casi todo el mundo, sobre todo a los que tienen Internet.
 Lo anterior lo digo porque no me cabe la menor duda de la ventaja de IPv6 para Santa, es la mejor forma de contactar a sus colegas en los países industrializados [1] donde absolutamente todos tienen cierto hasta bastante grado de penetración de IPv6, comenzando por Alemania con 33%, USA con 32%, Brasil, India y Francia con 21%, 23% y 22% respectivamente. Imaginense a Santa intentando comunicarse con esos países para pedir millones de regalos usando IPv4, sencillamente sería imposible.  Bien por estos países que se pusieron las pilas y obtuvieron un super cliente.
 Ahh, también quería contarles que me he dado cuenta lo difícil que es “perseguir virtualmente” a Santa, todos sabemos que vive en el Polo Norte, sin embargo gracias al uso de IPv6, la vasta cantidad de direcciones, el uso de direcciones IP de privacidad, no al uso de EUI-64 en las globales, quizás hasta un horroroso NAT66 me ha hecho imposible seguirlo cómodamente. Por cierto, he intentado de todo, publicidad, spam, cookies, cross site scripting, objetos embebidos y nada, definitivamente IPv6 si aumenta la privacidad. Bien por Santa !!
 Luego estuve pensando sobre los renos, el trineo y el tiempo de llevar las cosas alrededor del mundo.., creo que el concepto de Santa para movilizarse a través de los agujeros espacio - temporales [2] son propensos a fallas en IPv4.., con IPv6 y un NAT66 Stateless 1-1 (NPT) si funcionaría la cosa.
 Para los que no crean los agujeros espacio - temporales y apoyen más la teoría de de las nubes de relatividad [2] una vez más IPv6 es la respuesta…, para muestra un botón, todas las nubes hoy en día están en v6.
 Y finalmente, si no creen en ninguna de las dos anteriores, son los que apoyan la física cuántica [nuevamente 2], la explicación -mi favorita- es más sencilla aún: Santa debe tener una red de Elfos [3 ] anycasteados en todo el mundo lo que facilita su vida y puede entregar los regalos desde allí a las casas más cercanas, esta red seguro es Dual Stack, no podemos olvidarnos de los niños que tienen IPv4 por culpa que su ISP no le pone voluntad para poner IPv6. Pobres niños.


  En base a todo lo anterior, el despliegue de IPv6 es una muy buena noticia para Santa y más aún para los niños!!!.



Un fuerte abrazo y feliz navidad para todos.



Alejandro Acosta
@ITandNetworking
@LACNICLabs




viernes, 8 de diciembre de 2017

Comando oculto en Cisco. Deshabilitar negociacion de capacidad BGP

neighbor x.x.x.x dont-capability-negotiate

More info:
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/116189-problemsolution-technology-00.html


IoT Cybersecurity

Como determinar si un string es una dirección IPv4 o IPv6 en Python3

Hola,
  Escribo este post porque en varias oportunidades me han escrito como uno puede determinar si un string es una dirección IPv4 o IPv6 en Python3.

Solución 
  Nos apoyaremos en el módulo ipaddress de python3.
  Algo tan sencillo como esto:

a='2001:db8::1'
if ipaddress.ip_address(a).version == 6:
  print ('es IPv6')
else:
  print ('es IPv4')


 Espero te ayude,

miércoles, 15 de noviembre de 2017

Reto IPv6 - Lacnic - LACTF. Resumen 2017

Se han llevado a cabo 2 versiones del Reto LACNIC IPv6 en el 2017, durante mayo y septiembre, con la participación de 30 personas registradas de 7 países en ambas versiones, con 20 y 10 participantes, respectivamente, en forma individual o en grupo.

Se integró un Comité evaluador compuesto por 5 personas reconocidas en el tema de IPv6, todas integrantes del comité del FLIP6, cuyas funciones han incluido:
- Apoyar o sugerir pláticas de temas muy concretos que ayudaron a los participantes a tener más conocimientos y herramientas, para poner y ofrecer servicios con soporte de IPv6 en sus instituciones.
- Revisar los reportes de pruebas realizadas por los participantes.
- Validar el acceso y la disponibilidad de los servicios habilitados con IPv6.

De acuerdo a un monitoreo de los dominios de los portales web de los participantes, se verificó si algunos ya tenían asociadas direcciones IPv6 aunque la conectividad a los mismos no era exitosa, por lo que fue necesario demostrar la habilitación reciente de IPv6, el soporte de ambas versiones, y también de otros servicios que pudieran ofrecer en producción con ambas versiones del protocolo, cuidando los aspectos de seguridad y disponibilidad.
Todo lo anterior sirvió de elementos (puntos) para que el comité evaluador del Reto, pudiera tomar una decisión final de posible(s) ganador(res) del mismo.

Adicionalmente, se monitorearon dominios de sitios y estado de la habilitación de IPv6 en los servicios de las aplicaciones documentados por los participantes, antes, durante y después de la última versión de los reportes de avances.
Usando diferentes herramientas como “NAT64check” (https://nat64check.ipv6-lab.net/v6score) y comandos de conectividad como ping y traceroute. En la Fig.1 se muestra la prueba previa realizada al portal de uno de los finalistas de la versión 2 del Reto.



Fig. 1. Prueba previa realizada al portal de uno de los participantes del Reto

Se creó una sección en el Portal de IPv6 de LACNIC (http://portalipv6.lacnic.net/reto-ipv6) donde se incluyeron respuestas a las preguntas mostradas en la Fig. 2, del cartel promocional del Reto:


Fig. 2. Cartel promocional del Reto LACNIC IPv6

A los participantes de ambas ediciones del Reto se les ofreció un Webcast para aclarar dudas y recibir retroalimentación, además se creó una cuenta de correo con la participación del Comité evaluador.
En los reportes de avances se les solicitó reseñar lo realizado hasta cada momento (pruebas, reuniones con personal técnico y administrativo, etc.) para documentar:
- Reseña de la opción de obtención de bloque propio o usar el proporcionado por un proveedor (ISP). Si enviaron la solicitud de bloque al staff de LACNIC, indicando el status, y la documentación de los trámites.
- La indicación del grado de uso y anuncio del prefijo asignado con resultados de pruebas y el listado de servicios con soporte de IPv6.
- Aciertos y dificultades encontradas.
- Avances incrementales (# de servicios y usuarios con soporte de IPv6).
- Capturas de pantalla que comprobaran el punto anterior.
- En tablas con datos de los resultados de comandos como: ipconfig, ifconfig, ping, traceroute, netstat, etc.
- Indicación de los servicios que se ofrecieron también con IPv6.
- Confirmación del o los dominios de los servicios.
- Los pendientes y metas por lograr posteriormente.

Se fijaron varias fechas a cumplir por los participantes del Reto para el envío de una 1er. y 2a. versión del reporte de avances.

Así, en la retroalimentación del Reto de mayo, se recibieron 3 reportes de avance y tomando en cuenta sus aportaciones, se designaron 2 finalistas.
Por otra parte en la 2a. versión del Reto de septiembre, se recibieron únicamente 2 reportes de avance, por lo que la decisión de los finalistas fue más inmediata por parte del comité evaluador.

Finalmente después de cada premiación a los ganadores se les solicito, como parte de los resultados esperados de los datos de los reportes, el trabajar en un par de párrafos para publicar una nota al respecto en la publicación de LACNIC. Donde tuvieron que resumir lo realizado y comentar sobre la experiencia de participación en el Reto IPv6 LACNIC 2017 que incluyó lo que los impulsó a participar, los desafíos y dificultades sobre la implementación y uso de IPv6, los avances medibles, así como los procesos internos que se tuvieron que realizar y superar. Por lo que se les pidió contestar a las preguntas:

* ¿Qué los impulsó a participar en el Reto IPv6?
* ¿Con qué desafío se encontraron en el proceso?
* ¿Qué avances ha logrado implementar su institución en relación a IPv6?
* ¿Cree que las organizaciones son conscientes de la necesidad del despliegue de IPv6 o todavía piensan que lo ven como algo lejano?
* ¿Cómo ha sido el proceso interno en su institución para decidir avanzar en el despliegue de IPv6?
* ¿Cuáles son las principales dificultades a la hora de discutir sobre la implementación de IPv6?

Reflexión final:
Me ha parecido una experiencia muy alentadora la participación que espero se vaya incrementando y articulando con otras actividades dentro de LACNIC. Todos a final de cuentas seguimos aprendiendo de este tipo de iniciativas para mejorarlas y agregar más elementos al Reto mismo, como el grado de complejidad pero para motivar mas la participación, creatividad y obtener mejores resultados que se puedan dar a conocer.

El desafío a seguir promoviendo como una oportunidad de aplicar IPv6 en servicios en producción por parte de las entidades participantes miembros de LACNIC o de la región, sin lugar a dudas servirá para incrementar aún más el uso y despliegue de IPv6, compartir experiencias, y alentar a quienes no ven como caso de estudio y menos de negocio el habilitar servicios también con IPv6.

Referencias:

- Sección del Reto en el Portal de IPv6 de LACNIC (http://portalipv6.lacnic.net/reto-ipv6)
- Introducing NAT64 Checker
https://labs.ripe.net/Members/JanZorz/introducing-nat64-checker


Autor:
Azael Fernandez Alcantara
@lactf


jueves, 24 de agosto de 2017

Google DNS --- Averiguando cual Cluster estas utilizando

(this is -almost- a copy / paste of an email sent by Erik Sundberg to nanog mailing list on 
August 23). 
This post is being posted with his explicit permission.


I sent this out on the outage list, with a lots of good feedback sent to 
me. So I 
figured it would be useful to share the information on nanog as well.

A couple months ago had to troubleshoot a google DNS issue with Google’s 
NOC. Below 
is some helpful information on how to determine which DNS Cluster you are 
going to.

Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 
and 8.8.4.4. 
Anycast routes your DNS queries to the closes DNS cluster based on the 
best route / 
lowest metric to 8.8.8.8/8.8.4.4.   Google has deployed multiple DNS 
clusters across 
the world and each DNS Cluster has multiple servers.

So a DNS query in Chicago will go to a different DNS clusters than queries 
from a 
device in Atlanta or New York.


How to get a list of google DNS Cluster’s.
dig -t TXT +short locations.publicdns.goog. @8.8.8.8

How to print this list in a table format. 
Script from: https://developers.google.com/speed/public-dns/faq
---------------
#!/bin/bash
IFS="\"$IFS"
for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8)
do
  case $LOC in
    '') : ;;
    *.*|*:*) printf '%s ' ${LOC} ;;
    *) printf '%s\n' ${LOC} ;;
  esac
done
---------------

Which will give you a list like below. This is all of the IP network’s 
that google
uses for their DNS Clusters and their associated locations.

74.125.18.0/26 iad
74.125.18.64/26 iad
74.125.18.128/26 syd
74.125.18.192/26 lhr
74.125.19.0/24 mrn
74.125.41.0/24 tpe
74.125.42.0/24 atl
74.125.44.0/24 mrn
74.125.45.0/24 tul
74.125.46.0/24 lpp
74.125.47.0/24 bru
74.125.72.0/24 cbf
74.125.73.0/24 bru
74.125.74.0/24 lpp
74.125.75.0/24 chs
74.125.76.0/24 cbf
74.125.77.0/24 chs
74.125.79.0/24 lpp
74.125.80.0/24 dls
74.125.81.0/24 dub
74.125.92.0/24 mrn
74.125.93.0/24 cbf
74.125.112.0/24 lpp
74.125.113.0/24 cbf
74.125.115.0/24 tul
74.125.176.0/24 mrn
74.125.177.0/24 atl
74.125.179.0/24 cbf
74.125.181.0/24 bru
74.125.182.0/24 cbf
74.125.183.0/24 cbf
74.125.184.0/24 chs
74.125.186.0/24 dls
74.125.187.0/24 dls
74.125.190.0/24 sin
74.125.191.0/24 tul
172.217.32.0/26 lhr
172.217.32.64/26 lhr
172.217.32.128/26 sin
172.217.33.0/26 syd
172.217.33.64/26 syd
172.217.33.128/26 fra
172.217.33.192/26 fra
172.217.34.0/26 fra
172.217.34.64/26 bom
172.217.34.192/26 bom
172.217.35.0/24 gru
172.217.36.0/24 atl
172.217.37.0/24 gru
173.194.90.0/24 cbf
173.194.91.0/24 scl
173.194.93.0/24 tpe
173.194.94.0/24 cbf
173.194.95.0/24 tul
173.194.97.0/24 chs
173.194.98.0/24 lpp
173.194.99.0/24 tul
173.194.100.0/24 mrn
173.194.101.0/24 tul
173.194.102.0/24 atl
173.194.103.0/24 cbf
173.194.168.0/26 nrt
173.194.168.64/26 nrt
173.194.168.128/26 nrt
173.194.168.192/26 iad
173.194.169.0/24 grq
173.194.170.0/24 grq
173.194.171.0/24 tpe
2404:6800:4000::/48 bom
2404:6800:4003::/48 sin
2404:6800:4006::/48 syd
2404:6800:4008::/48 tpe
2404:6800:400b::/48 nrt
2607:f8b0:4001::/48 cbf
2607:f8b0:4002::/48 atl
2607:f8b0:4003::/48 tul
2607:f8b0:4004::/48 iad
2607:f8b0:400c::/48 chs
2607:f8b0:400d::/48 mrn
2607:f8b0:400e::/48 dls
2800:3f0:4001::/48 gru
2800:3f0:4003::/48 scl
2a00:1450:4001::/48 fra
2a00:1450:4009::/48 lhr
2a00:1450:400b::/48 dub
2a00:1450:400c::/48 bru
2a00:1450:4010::/48 lpp
2a00:1450:4013::/48 grq

There are
IPv4 Networks: 68
IPv6 Networks: 20
DNS Cluster’s Identified by POP Code’s: 20

DNS Clusters identified by POP Code to City, State, or Country. Not all of 
these are 
Google’s Core Datacenters, some of them are Edge Points of Presences (POPs). 
https://peering.google.com/#/infrastructure and 
https://www.google.com/about/datacenters/inside/locations/

Most of these are airport codes, it did my best to get the location correct.
iad          Washington, DC
syd         Sydney, Australia
lhr          London, UK
mrn        Lenoir, NC
tpe         Taiwan
atl          Altanta, GA
tul          Tulsa, OK
lpp          Findland
bru         Brussels, Belgium
cbf         Council Bluffs, IA
chs         Charleston, SC
dls          The Dalles, Oregon
dub        Dublin, Ireland
sin          Singapore
fra          Frankfort, Germany
bom       Mumbai, India
gru         Sao Paulo, Brazil
scl          Santiago, Chile
nrt          Tokyo, Japan
grq         Groningen, Netherlans



Which Google DNS Server Cluster am I using. I am testing this from 
Chicago, IL
# dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8
"173.194.94.135"                     <<<<<dig o-o.myaddr.l.google.com -t 
txt +short @8.8.8.8
"74.125.42.138" "173.194.102.132" "74.125.177.5" "74.125.177.74" "74.125.177.71" 
"74.125.177.4" Which all are Google DNS Networks in Atlanta. 74.125.42.0/24 atl 
 74.125.177.0/24 atl 172.217.36.0/24 atl 173.194.102.0/24 atl 2607:f8b0:4002::/48 atl

 Just thought it would be helpful when troubleshooting google DNS issues.



(one more time: this is -almost- a copy / paste of an email sent by Erik Sundberg to nanog mailing 
list on August 23). This post is being posted with his explicit permission.


Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...