VPSs y mas.

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

martes, 5 de junio de 2018

Concepto: ¿Qué es un plan de direccionamiento IP(v4|v6)?


"Se define como el modo, las acciones, el modelo sistemático para llevar a cabo las asignaciones de direcciones IP (IPv4 y/o IPv6) en una red"



P.D. Concepto realizado por mí persona mezclando diversas definiciones de la palabra "plan" y haciendo enfoque  al mundo IP

lunes, 21 de mayo de 2018

Todos los root servers DNS con soporte IPv6 - Un hito que pasó desapercibido

Introducción

En esta oportunidad quiero hablar sobre un detalle que considero pasó en el mundo de Internet desapercibido, tanto así que yo mismo ni me dí cuenta tarde.

Un poco de historia

Recientemente estuve revisando unas presentaciones de hace pocos años (aprox 2015) y noté que en las mismas mencionaban que solo 11 de los 13 root servers tenían direccionamiento IPv6. Por ello quise chequear y para mi sorpresa hoy -Mayo 2018- los 13 Root Servers cuentan con direccionamiento IPv6.
Los últimos nuevos glues IPv6 fueron modificados de la siguiente manera y en la siguiente fecha: 20 octubre 2016: g.root-servers.net . AAAA 2001:500:12::d0d 25 agosto 2016: e.root-servers.net . AAAA 2001:500:a8::e
Y fue anunciado el 2 de diciembre del 2016: http://root-servers.org/news/announcement-of-ipv6-addresses.txt
Actualmente los root servers tienen estas direcciones -Tomado de https://www.internic.net/domain/named.root -
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 3600000 A 199.9.14.201
B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:200::b
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
C.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2::c
D.ROOT-SERVERS.NET. 3600000 A 199.7.91.13
D.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2d::d
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
E.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:a8::e
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2f::f
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
G.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:12::d0d
H.ROOT-SERVERS.NET. 3600000 A 198.97.190.53
H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::53
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
I.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fe::53
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:c27::2:30
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fd::1
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:9f::42
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
M.ROOT-SERVERS.NET. 3600000 AAAA 2001:dc3::35

¿Cómo algo tan importante pudo pasar desapercibido?

Desde nuestro punto de vista fue increíble que este hecho no tuviese más difusión, pero las cosas fueron así y no podemos hacer nada al respecto. Se nos ocurren algunas razones por qué hubo esa falta de difusión:
  1. IPv6 ya se encuentra tan avanzado y estable que no pasó a ser noticia. Por ejemplo, en el 2008 cuando se colocó la primera dirección IPv6 si existió mucha noticia por muchas listas de correo y otros medios.
  2. Algunas noticias pasan sin pena ni gloria sobretodo cuando no hay pena como en esta oportunidad (que viene a ser bueno !!)
    Una comparación que suena exagerada pero cala perfectamente en este contexto es cuando llegó el Apollo 11 a la luna en el año 1969, fue una gran noticia, en los posteriores proyectos Apollo ya la misma novedad no tenía mucho impacto.

¿Qué significa que ahora todos los Root Servers DNS cuenten con IPv6?

Para este renglón existen dos cosas que podemos mencionar que son muy significativas, 1) es un mensaje adicional a la comunidad que IPv6 es un protocolo estable y funcional 2) podemos esperar resoluciones más rápidas y con menores rata de falla.
Un punto adicional, es importante indicar que la ausencia de NAT en IPv6 dentro del mundo DNS tiene particular y mayor relevancia motivado a que los traductores no necesitan Natear las respuestas DNS.
Por último, esto también empuja a crear demanda por IPv6 en todo el mundo. No olvidemos que los root servers utilizan anycast desde hace muchos años, y cada uno de los más de 1.000 nodos tienen requerimiento de servicio IPv6 en las decenas de países y redes en que son hosteados.
El siguiente paso entonces es... ir apagando IPv4 en alguno de los root servers! ;)

Referencias

Por

Alejandro Acosta
Colaborador: Hugo Salgado

miércoles, 9 de mayo de 2018

IPv4 e IPv6 en una sola VPN utilizando OpenVPN

Introducción
  Recientemente conversando con un amigo (@TarantinDigital) me indicaba que le gustaría tener una VPN que soportara IPv4 e IPv6, que le parece una solución muy interesante para IoT.
  Igualmente entre otras cosas ofrece la comodidad de tener direccionamiento IPv6 persistente (siempre el mismo bloque IPv6)

Importante
  No voy a indicar los pasos para instalar o configurar OpenVPN.
  Asumo tienes un servidor OpenVPN corriendo y en el servidor tienes direccionamiento IPv4 e IPv6
  Nos enfocaremos en algunas entonaciones en el servidor y en el archivo server.conf
  Este excelente video (en Ingles) ofrece paso a paso como instalar y configurar OpenVPN: https://www.youtube.com/watch?v=XcsQdtsCS1U

Pasos para agregar IPv6 a un servidor OpenVPN que actualmente ofrece solo IPv4 
  1) Tu interfaz tun (o TAP) tiene que tener direccionamiento IPv6, OpenVPN tiene algunas restricciones en cuando a la longitud de prefijo (*máscara*) que puede utilizar en IPv6, para este ejemplo estaré utilizando un /64
  ifconfig tun0 add 2001:db8::1/64


  2) Es necesario (para nuestro ejemplo, si utilizas un /64 global de IPv4 o direccionamiento IPv4 público no sería necesario) realizar NAT44 y NAT66:

  NAT44
  iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to xx.xx.xx.xx

  NAT66

  ip6tables -t nat -A POSTROUTING -o eth0 -s 2001:db8::/32 -j MASQUERADE #noten que en eth0 hay un IPv6 global


  3) Hay que agregar algunas directivas de IPv6 en el archivo /etc/openvpn/server.conf. Las mismas son las siguientes:


  proto udp6 #hará que el server maneje sockets v4 y v6
  server-ipv6 2001:db8::1/64  #dirección IP colocada a la interfaz tun en el server openvpn
  tun-ipv6 #tipo de interfaz tunnel con IPv6 
  push tun-ipv6   #se le pide al cliente crear interfaces tun para el tunel (la VPN)
  ifconfig-ipv6 2001:db8::1 2001:db8::2
  push "route-ipv6 2000::/3" #inyecta esta ruta en el cliente

  4) Finalmente es necesario convertir el servidor VPN en un router IPv6. Para ellos editamos el archivo /etc/sysctl.conf y la linea net.ipv6.conf.all.forwarding=1 le quitamos el #


Del lado del cliente veras una interfaz similar a:
utun1: flags=8051 mtu 1500
inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff 
inet6 fe80::aebc:32ff:fe96:822b%utun1 prefixlen 64 scopeid 0xd 

inet6 2001:db8::1001 prefixlen 64 



Note que recibió una dirección IPv6 del mismo /64 de la interfaz tun del servidor.

Espero sea de tu utilidad


Referencias
  https://www.youtube.com/watch?v=XcsQdtsCS1U
  http://blog.acostasite.com/2014/07/nat66-en-linux.html





miércoles, 11 de abril de 2018

Identificando servidores DNS IPv6 Open Resolvers

Introducción

Como muchos de ustedes saben, tener servidores DNS Open Resolvers es muy negativo, tanto para el que deja el servicio abierto como para la seguridad en Internet en general.
Este tipo de servidores se utilizan como vector de ataques de DDoS por amplificación ya que a partir de un mensaje de consulta de pequeño tamaño, se puede obtener una respuesta mucho mayor. De esta manera, ese servidor DNS se convierte en un amplificador de tráfico muy potente ya que sus consultas amplificadas pueden dirigirse a una IP específica, la cual recibiría todo ese volumen de tráfico, ocasionándole indisponibilidad de sus servicios. Para este ataque ni siquiera es necesario que el hardware esté controlado por el atacante.
Este es un problema que en WARP nos preocupa porque hemos recibido mucho reportes de incidentes relacionados a esta vulnerabilidad. Por esta razón en conjunto con el área de I+D estamos llevando a cabo un proyecto con el objetivo de conocer el estado actual de la región, identificar los open resolvers y de forma proactiva alertar y recomendar una posible corrección de la configuración de este servicio.

Identificando un DNS Open Resolvers en IPv6 (DNS abiertos)

Identificar servidores Open Resolvers o servidores DNS abiertos en el mundo de IPv4 es muy sencillo, debido a la poca longitud del espacio de IPv4 (2**32).
En el mundo de IPv6 es imposible poder verificar cada una de las direcciones IP y ejecutar una prueba de Open Resolver. Dicha prueba puede durar miles de años.

¿Cómo se identifica un DNS Open Resolver?

Un servidor DNS recursivo solo debería responder consultas (queries) a todos los clientes que se encuentren dentro de su misma red y debería rechazar cualquier otra que provenga de fuera. Por ejemplo, los servidores DNS del ISP ACME solo deberían responder a consultas de sus propios clientes, a más nadie.
La identificación se hace realizando una consulta de un nombre de dominio a los servidores DNS. En caso que el servidor DNS responde con una respuesta válida, entonces es considerado Open Resolver. Si por el contrario, devuelve un rechazo (Query refused) o sencillamente hace timed out se encuentra bien configurado, por lo que no es un Open Resolver.

¿Cómo se consiguen los resolvers de IPv6?

LACNIC administra un servidor que puede ser llamado: Root Server Reverso, específicamente la letra “D”, es decir, d.ip6-servers.arpa. Gran cantidad de consultas a direcciones IP reversas de la región de LACNIC pasan a través de este servidor, en líneas generales este servidor SOLO recibe consultas de servidores DNS. Aquí es donde obtienen las direcciones IPv6 de los DNS que realizan consultas.

Procedimiento & Algoritmo

    1. En el servidor actualmente se realiza una captura de 2.5 millones de paquetes con el filtro del puerto 53 y destinados únicamente a la dirección IP de dicho equipo.
    2. De la captura anterior se ubican solo direcciones IPv6 origen (se eliminan paquetes mal formados, errores, etc). Se desprecia menos de 1% de los paquetes
    3. De las direcciones IPv6 obtenidas en el paso 2 se crea una lista de direcciones IPs unicast (es decir, se eliminan duplicados)
    4. Un script toma cada dirección IPv6 del listado del punto 3, y realiza una consulta a la dirección www.lacnic.net hacia esa dirección, verifica recursividad y el estado de la respuesta.
    5. En caso de ser un Open Resolver dicha dirección IP quedará registrada para su posterior análisis y notificación a la organización responsable de ese recurso.

Diagrama de bloques

Vista de los Resultados

Conclusiones Primarias

Para esta primera instancia, observamos aproximadamente unos 33,514 registros de consultas realizadas al Root Server Reverso “D” administrado por LACNIC.
Luego de analizar estos primeros datos obtenidos, observamos que la región más afectada por servidores open resolver sería la de APNIC con el 19.23% de los datos obtenidos para esa zona. Para la región de Ripe obtuvimos la mayor cantidad de información, curiosamente el porcentaje de servidores mal configurados es casi insignificante (0.93%).
En lo que respecta a nuestra región detectamos 39 open resolvers (4.56%) de los 817 registros recolectados, donde existen solo 3 casos que la dirección IP se repite más de una vez.

Estudios similares

Referencias

Para leer sobre Open Resolvers se recomienda este link: https://www.certsi.es/blog/dns

Realizado por:

Dario Gomez & Alejandro Acosta


viernes, 22 de diciembre de 2017

Retrospectiva de crecimiento IPv6 durante el 2017 en LAC

Hola de nuevo,
Este es un post que ya se ha venido convirtiendo en tradición en los últimos años. Básicamente lo que busco es realizar un resumen de cambios relevantes de IPv6 para algunos países de la región. Les prometo me gustaría mencionarlos a todos pero es imposible !
En esta oportunidad voy a comenzar recordando 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.”
Adicionalmente deseo dar continuidad a una frase que utilicé el año pasado para este mismo artículo el cual se lee:
“Volviendo a la retrospectiva, creo que 2016 marcó un hito importante en cuanto al crecimiento del protocolo. Quiero decir, ya no hay vuelta atrás. Si algunos aún pensaban que IPv6 era bueno, era malo, le faltaba seguridad, robustez, todas las anteriores.., pueden tener razón :-) pero aún así su despliegue lo considero imparable.“
Debo decir con toda seriedad que mantengo esas mismas palabras. En el 2017 vimos un crecimiento en Latam bastante alto impulsado por diferentes países y por muchos proveedores. Algo diferente a lo apreciado en años anteriores

¿Que ha pasado con los países de LAC durante el 2017? [2]

Uruguay

Comienzo con este país porque lo realizado en el 2017 no tiene comparación. Siendo un país de 3.5 mm de habitantes y de 176.000 km2 su grado de penetración de IPv6 en este momento es de 30% (comenzó el año en 0%). Si revisamos el ranking mundial de penetración de IPv6, UY está de 5ta posición, y lo mejor aún, con un franco crecimiento que no parece cambiar en el corto plazo. ¡ Vamos arriba UY !.

Argentina

Seguimos en el sur. Los indicadores de Argentina tuvieron sus primeros movimientos a mediados del 2016, sin embargo hay que notar que este año duplicaron su grado de penetración de IPv6 en el usuario final, comenzaron el año con menos de 2% y finalizan con más de 6%. ¡ Felicitaciones!

Perú

Hubo una época que hablar de IPv6 en Latam era casi hablar de Perú, por varios años este país fue un icono en la región. Estuvo quieto por un tiempo y a mediados de este año se les vió otro repunte.., al menos dos operadores adicionales están trabajando con v6 lo que hizo aumentar la penetración de v6 en el usuario final de 15 % a 20%. ¡Que alegría Perú!

Brasil

No podemos terminar este artículo sin mencionar al gigante de la región, un país de más de 8.000.000 km2 y de > de 200.000.000 de habitantes. Lo interesante de IPv6 y BR es la gran cantidad de distintos actores que están moviendo la aguja. Comenzaron el año con aproximadamente 11% de IPv6 en el usuario final y están terminando con más de 22%. Un gran salto para un gran país. ¡Moito bem feito!

¿Y el promedio para todo LATAM?

El 1 de Enero de 2017 el promedio de acceso IPv6 en LATAM fue de 2.26 %, hoy en día está sobre 4.27%. Esto representa un crecimiento de 94%..., 24 puntos por arriba de lo que fue en el 2016. Cuando veo estos números siempre pienso que las personas que tengan servicios hacia al cliente en Internet tienen que considerar la gran cantidad de potenciales visitantes/usuarios en v6.

¿Y sobre el mundo de contenido/servidores?

El 2017 fue un año muy bueno en este sentido, sobre todo en el segundo semestre escuchamos de varios operadores que desplegaron IPv6 en sus Data Centers, proveedores de hosting colocaron registros AAAA en los DNS apuntando a servidores Web. Varios miles de dominios en nuestra región fueron habilitados con IPv6 en el año 2017. Creo que no podemos pedir más, solo fueron buenas noticias.

¿Qué esperar para el 2018?

No soy pitoniso pero no creo que sea muy difícil pronosticar el 2018, creo que veremos gran cantidad de operadores desplegando IPv6, veremos más IPv6 en el usuario final. Las estadísticas de acceso seguirán con un crecimiento constante y estable. Creo que tendremos un repunte también en la parte de contenido IPv6 en nuestra región, confiamos que muchos proveedores y Data Centers habilitarán IPv6 en el corto/mediano plazo.
Reciban un fuerte abrazo,
#Referencias
  1. https://es.wikipedia.org/wiki/Retrospectiva
  2. http://stats.labs.lacnic.net/IPv6/graph-access.html

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

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

martes, 6 de septiembre de 2016

Ejemplo: Linux y Network Prefix Translation (NPT)

Introducción:
En este post voy a intentar explicar brevemente que es NPT, por qué es útil y finalmente dejaré un pequeño ejemplo que espero sea de utilidad.


¿Qué es NPT?
NPT por sus siglas en Inglés significa Network Prefix Translation, algunos lo podrás comparar con NAT en IPv6.., y bueno,., es medianamente cierto. Siendo la palabra “medianamente” perfectamente utilizada en la oración previa.


En NPT básicamente lo que se busca es traducir la dirección origen en un datagrama IPv6, pero particularmente la sección del prefijo de red (NET ID) dejando la parte del IID (Host ID) sin modificación.


¿Por qué hacer NPT?
Existen varias razones. Voy a mencionar solo dos.


  1. Estoy en una red con dos proveedores de Internet (no tengo IPs propias ni ASN), pero necesito alguna redundancia para salir a Internet. El equipo de borde en vez de realizar un NAT con sobre de carga de puertos a una sola dirección IP (con todos los problemas y limitantes que esto ocasiona) solo modifica los primeros bits del la dirección (digamos, los primeros 64 bits solo como manera de ejemplo).
  2. Si necesitar hacer “renumbering” de tu red pero tienes IPs del tipo ULA (u otra propia quizas) tu vida será mucho más sencillo al solo tener que modificar el traductor NPT y no hacer re-enumeración de toda la red.


Diagrama ejemplo


Configurando un equipo Linux para hacer NPT:


Los pasos para configurar NPTv6 (o NPT) en Linux son muy sencillos. Debes hacerlo tanto de paquetes salientes como de paquetes entrantes.


#From internal network to external Network
ip6tables -t nat -A POSTROUTING -d 2000::/3 -s 2001:db8:AAAA:AAAA::/64 -j NETMAP
--to 2001:db8:CCCC:CCCC::/64;


#From external network to internal network
ip6tables -t nat -A PREROUTING -s 2000::/3 -d 2001:db8:CCCC:CCCC::/64 -j NETMAP
--to 2001:db8:AAAA:AAAA::/64;


Mas info:


Y por supuesto el RFC mismo: