IPv6 y Enlaces Satelitales: La solución correcta para el resto del mundo

Resumen:

 Hoy en día, el acceso a Internet es un derecho. Es como tener electricidad y agua. Siendo un extremista, me atrevería a decir que es como el oxígeno en algún modo.

 Este pequeño post trata de resumir una simple combinación de tecnologías que se supone sea una solución a largo plazo para lugares remotos donde el acceso a Internet es generalmente difícil de conseguir.

 Una de las metas de la humanidad de hoy debe ser la de ofrecer un buen acceso, seguro, libre, sin bloqueos a la información y fiable a Internet a todo el mundo, sin importar la locación del individuo. Nuestra motivación actual se orienta a lugares donde un enlace terrestre es imposible de encontrar. Entiendase como terrestre, Wireless, Radio, Fibra, Cobre, etc, etc.

 Básicamente queremos mezclar dos conocidas tecnologías que lamentablemente pienso aun no estan trabajando de la mano: 1) los enlaces por satélite y 2) IPv6. La primera de ellas, con la ventaja de alcanzar casi cualquier rincón del planeta. El segundo, es el estándar de facto para el futuro próximo.

Introducción:

 En los últimos 14 años de mi vida he estado trabajando en el área de enlaces satelitales. Además, desde 1998 he tenido curiosidad acerca de IPv6, pero fue no fue hasta hace siete años que he tenido la oportunidad de trabajar e implementarlo en redes en producción. Por último, siempre he sido un apasionado de Internet, las comunicaciones y la libertad de acceso a la información.

Siendo mis bases muy técnica mi orden de preferencia en el mundo de últimas millas (enlaces) van en este orden: 1) Enlaces cableados (Fibra, Cobre), 2) luego enlaces inalambricos terrestres (microondas, Wi-Fi, WiMAX, Celular etc) y 3) finalmente enlaces satelitales. Los dos primeros por diferentes razones no siempre son posibles, principalmente en zonas remotas, rurales y topologicamente dificiles.

Propuesta:

 Una de las cosas maravillosas de los enlaces por satélite, es su capacidad de llegar a prácticamente cualquier lugar del mundo. Ha lo largo de mi experiencia he tenido la oportunidad de participar en las instalaciones portuarias de enlaces satelitales, en lugares muy remotos, tales como embarcaciones, en sitios rurales o selváticos remotos donde no hay ni señal de teléfono celular. A su vez he visto todo tipo de soluciones implementadas en estos enlaces: ATM (cajeros automáticos), POS (Punto de Venta), agencias bancarias, enlace empresarial privado y por supuesto: acceso a Internet donde he visto VoIP, VPNs y aplicaciones regulares como correo electronico y navegación.

 Durante los últimos años he estado profundamente involucrado con IPv6. Yo soy un firme creyente en el concepto "Internet de las cosas", donde la mayoría de los dispositivos estarán conectados a Internet. IPv6 ofrece una cantidad de ventajas que aún estamos esperando conseguir, el dia (no muy lejano) que sea IPv6 se implemente de extremo a extremos entre la mayoría de los internautas el sin fin de servicios que veremos será notable.

 Desafortunadamente, por diversos  motivos,  el pensamiento convencional -principalmente en paises en vias de desarollo- es que  las conexiones a Internet son eficientes en los sitios urbanos. Esto es parcialmente cierto y es exactamente donde quiero llegar con este artículo, no debemos olvidar las grandes masas de población (y cosas) en las zonas no urbanas, notablemente mayor en los países en vias desarrollo. Al final, este hecho se vuelve muy negativo. Estas personas en el mundo rural (millones) se están quedando atrás, cuando las ventajas de la conexión de poseer Internet son excesivamente notables, por mencionar tan solo algunas: el acceso a e-learning, e-nursering (enfermería), la telemedicina, la investigación, el cloud computing, las consultas en línea y muchos otros beneficios que ofrece. Una vez más, el acceso debe ser libre, eficiente, no restringida, seguro y sin bloqueos a ningún tipo de información.

 Aunque enlaces como fibra, híbrida fibra-coaxial y enlaces inalámbricos de muy alta velocidad están creciendo en todos los países, hay lugares donde nunca se ven estas tecnologías o no podrán contar con estos durante varias décadas. La solución que veo venir, y que debemos mantener, es la pareja formada por el nuevo protocolo de Internet (IPv6) y las comunicaciones por satélite.  Sabemos existen enlaces por satélite en todas partes e IPv6 como “nuevo” protocolo va creciendo y avanzando, por lo que mi propuesta es combinar ambas tecnologías.

En mi opinión, esta combinación es la única que realmente ofrece una viabilidad a largo plazo, siendo factible en la actualidad.  Esta es la mejor manera de conectar a todos en el “resto” mundo.

Desafortunadamente los fabricantes de tecnología por satélite han sido de los últimos en ofrecer soluciones basadas en IPv6. En la actualidad, si colocamos en un buscador de Internet algo así como: "IPv6 hubs satelitales " no obtendrá un enlace con información concreta al respecto. En mi experiencia, el año pasado sólo había un fabricante de Hub satelitales que habia añadido soporte IPv6 para su solución. Dicho esto, hemos visto un cambio, aunque pequeño, por un solo proveedor de equipos. No parece haber en el mercado varias opciones satelitales con IPv6 de manera nativa. Mi creencia es que con un poco de apoyo y colaboración de la comunidad, y probablemente de alguna organización,podemos hacer esta combinación un "deber ser" entre los proveedores satelitales. Pensamos que si la industria de satélites   sigue creciendo sin IPv6, será peor para ellos a largo plazo. Nuestra hipótesis se basa en que IPv6 tiene que ser la manera de llegar a donde solo los satélites son capaces. En pocas palabras: 1) La falta de IPv6 en la tecnología satelital en esos lugares le hará daño al desarrollo tecnologico, 2) Esos lugares no podrán disfrutar de algunos de los beneficios que ofrece IPv6.

 Por último, me gustaría mencionar que los problemas tradicionales que se encuentran en los enlaces por satélite, tales como: 1) Retardo de ida y vuelta y 2) los costos; ya están siendo resueltos con modernas tecnologías. También hay algunas nuevas iniciativas que impulsará aún más esta situación.

Conclusión:

 La combinación de enlaces satelitales e IPv6 es la manera correcta de alcanzar ese 50% de población que no tiene Internet en Latinoamérica, la manera correcta de ofrecer servicios básicos de Internet en nuevos clientes, la forma correcta de crear nuevos servicios en la nube y es la única solución existente para enfrentar el agotamiento de IPv4.
Locators is the command that tells Selenium python to identify elements, find_element_by_id, find_element_by_XPath, find_element_by_link_text, find_element_by_tag_name, find_element_by_class_name, find_element_by_css_selector. Selenium find element by class Thereby, we can say that more effective the locator is, stabler will be the automation script. Every pythn bindings requires locators to find web elements. I hope this gives you a clear understanding of how find element by class locator works in pyth
read the info
read the info

NAT66 en Linux

Hola,

  El dia de hoy voy a hacer un post el cual no deseo que sea tomado de mala manera. Indiscutiblemente no estoy a favor del NAT pero aun asi pienso que es un mecanismo que no desaparecera en IPv6 (se reducira drasticamente) pero siempre existira. En lo posible recomiendo evitar hacer NAT cuando exista la posibilidad.

  Pueden haber muchas razones para implementar NAT66, a) seguramente los clientes acostumbrados a hacer NAT querran hacerlo en IPv6 (suene feo o bonito), b) personas que quieran ocultar su topologia a Internet, c) empresas que consideren NAT como mecanismo para cambiar los IPs de sus redes, d) la tendencia mundial de no permitir tethering en los celulares, e) querer ofrecer IPv6 detras de un dispositivo y mi proveedor no tenga DHCPv6-PD o solo me entregue una red /64, f) alguien que piense que NAT sirve de mecanismo de seguridad, etc, etc, etc, etc.

  En base a lo anterior la intencion de este post no es estar a favor o en contra de NAT, solo deseo indicar que esta disponible en el mundo de IPv6 y ofrecer un sencillo ejemplo. Para bien o para mal puede ser utilizado en algunos escenarios.

Requerimientos:

  El equipo a realizar el NAT66 debe tener:

  - Kernel > 3.9 

  - iptables > 1.4.18

  Ubuntu 14.04 cubre ambos requerimientos "out-of-the-box" y por ello es muy sencillo hacerlo.

  Existen patch para hacer NAT66 en versiones previas pero no lo indicare en este momento.

Escenario:

  Esta es la topologia en la que estoy trabajando. Deseo que "Device 2"  traduzca la direccion IPv6 origen de "Device 1" con la direccion IPv6 de la interfaz saliente (eth2). Con el comando NAT implementado estoy realmente haciendo NAT de toda la subred 2001:db8:12::/48

Configuraciones:

En DEVICE 1:

#ifconfig eth0 inet6 add 2001:db8:12::2/48

#route -A inet6 add default gw 2001:db8:12::1

En DEVICE 2:

Configurar las direcciones IPv6 en el equipo

#ifconfig eth1 inet6 add 2001:db8:12::1/48

#ifconfig eth2 inet6 add 2001:db8:23::1/48

Habilitar enrutamient o IPv6 entre las interfaces:

#sysctl -w net.ipv6.conf.all.forwarding=1

Configurar el NAT66:

#ip6tables -t nat -A POSTROUTING -o eth2 -s 2001:db8:12::/48 -j MASQUERADE

(es de notar que existen muchas otras maneras de hacer NAT con ip6tables)

En DEVICE 3:

#ifconfig eth1 inet6 add 2001:db8:23::2/48

#route -A inet6 add default gw 2001:db8:23::1

  Del lado de Device 3 pueden verificar de muchas maneras que todo funcione, incluso sin ruta por default en Device 3, DEVICE 1 puede llegarle. De igual manera tcpdump, wireshark o una sencilla revision de los logs puedes verificar que efecticamente el NAT esta llevandose a cabo.

  Espero sea de tu utilidad

Super sencillo sniffer en python3

Hola,
  Luego de mucho sufrir y mucho buscar logre adaptar con muy pocos cambios un sniffer que esta en python2 y llevarlo a python3...,  es el unico sniffer que me ha funcionado usando python3.3. Lamentablemente es MUY basico pero creo que alguien le puede servir, por ello se los dejo.
  Al menos captura y muestra origen, destino, puertos TCP e incluso la data en hex. Lo que no he podido hacer es "unpack" la data sobre TCP.

-----

#!/usr/bin/python3.3
#Sniffs only incoming TCP packet

import socket, sys
from struct import *

#create an INET, STREAMing socket
try:
    s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_TCP)
except:
    print ('Socket could not be created. Error Code : ' + str(msg[0]) + ' Message ' + msg[1])
    sys.exit()

# receive a packet
while True:
    packet = s.recvfrom(65565)
     #packet string from tuple
    packet = packet[0]

    #take first 20 characters for the ip header
    ip_header = packet[0:20]

    #now unpack them :)
    iph = unpack('!BBHHHBBH4s4s' , ip_header)
   
    version_ihl = iph[0]
    version = version_ihl >> 4
    ihl = version_ihl & 0xF

    iph_length = ihl * 4
    ttl = iph[5]
    protocol = iph[6]
    s_addr = socket.inet_ntoa(iph[8]);
    d_addr = socket.inet_ntoa(iph[9]);

    print ('Version : ' + str(version) + ' IP Header Length : ' + str(ihl) + ' TTL : ' + str(ttl) + ' Protocol : ' + str(protocol) + ' Source Address : ' + str(s_addr) + ' Destination Address : ' + str(d_addr))

    tcp_header = packet[iph_length:iph_length+20]

    #now unpack them :)
    tcph = unpack('!HHLLBBHHH' , tcp_header)

    source_port = tcph[0]
    dest_port = tcph[1]
    sequence = tcph[2]
    acknowledgement = tcph[3]
    doff_reserved = tcph[4]
    tcph_length = doff_reserved >> 4

    print ('Source Port : ' + str(source_port) + ' Dest Port : ' + str(dest_port) + ' Sequence Number : ' + str(sequence) + ' Acknowledgement : ' + str(acknowledgement) + ' TCP header length : ' + str(tcph_length))

    h_size = iph_length + tcph_length * 4
    data_size = len(packet) - h_size

    #get data from the packet
    data = packet[h_size:]

    print ('Data : ' + str(data))
    print ()


(solo captura TCP pero es muy sencillo adaptarlo a otros protocolos)
------

Basado en:

http://www.binarytides.com/python-packet-sniffer-code-linux/

Solucion a tres errores cuando queremos arrancar ISC DHCP 4.3

Error 1: 
Can't open lease database /var/lib/dhcp/dhcpd6.leases: No such file or directory --
  check for failed database rewrite attempt!

Ejemplo:
root@IPv6-RTR:/etc#  /usr/sbin/dhcpd -6 -f -cf /etc/dhcp/dhcpd.conf eth5
Internet Systems Consortium DHCP Server 4.3.0a1
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Can't open lease database /var/lib/dhcp/dhcpd6.leases: No such file or directory --
  check for failed database rewrite attempt!
Please read the dhcpd.leases manual page if you
don't know what to do about this.
root@IPv6-RTR:/etc# touch /var/lib/dhcp/dhcpd6.leases


Solucion a error 1:
#touch /var/lib/dhcp/dhcpd6.leases

Adicionalmente verificar si el usuario con el que se esta ejecutando dhcpd posee escritura en /var/lib/dhcp

Quizas tambien hay que:
#cd /var/lib/
#chown -R root.root dhcp

--------------------------

Error 2:
   No subnet6 declaration for eth5 (fe80::a00:27ff:fee7:b7c)

Ejemplo del error:
root@IPv6-RTR:/etc/dhcp# /usr/sbin/dhcpd -6 -f -cf /etc/dhcp/dhcpd.conf eth5
Internet Systems Consortium DHCP Server 4.3.0a1
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Wrote 0 NA, 0 TA, 0 PD leases to lease file.

No subnet6 declaration for eth5 (fe80::a00:27ff:fee7:b7c).
** Ignoring requests on eth5.  If this is not what
   you want, please write a subnet6 declaration
   in your dhcpd.conf file for the network segment
   to which interface eth5 is attached. **


Not configured to listen on any interfaces!


Solucion a error 2:
   Quitar la declaracion de subnet6 en dhcpd6.conf y copiarla a dhcpd.conf

-------------------------

Error 3:
   Can't set SO_REUSEPORT option on dhcp socket: Protocol not available

Ejemplo del error:

root@IPv6-RTR:/etc/dhcp# /usr/sbin/dhcpd -6 -f -cf /etc/dhcp/dhcpd.conf eth5
Internet Systems Consortium DHCP Server 4.3.0a1
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Wrote 0 NA, 0 TA, 0 PD leases to lease file.
Can't set SO_REUSEPORT option on dhcp socket: Protocol not available

Solucion a error 3:
 Actualizar el kernel a una version >= 3.9

SO_REUSEPORT es requerido por ISC DHCP 4.3 por ello es necesario tener un kernel > 3.9

Instalar ISC DHCP 4.3 en Linux (Ubuntu 13.04) (IPv6)

Situacion:
  Deseo instalar DHCP ISC 4.3 en Linux para mejorar el soporte de DHCP para IPv6.

Procedimiento:
  1) Agregar la siguiente linea al final de /etc/apt/sources.list:

deb http://ftp.de.debian.org/debian experimental main

  2) Eliminar cualquier dhcp de ISC que tuviesemos antes:

#apt-get purge isc-dhcp-server  (notese que podemos usar purge o remove, lo dejo a tu criterio)


  3) Actualizar la DB de repositorios:
#apt-get update

  4) Instalar el isc-dhcp-server indicando que use el repositorio experimental:

 #apt-get -t experimental install isc-dhcp-server


Importante:
  La configuracion del DHCP(d) debe estar funcionando, sino, el DHCPD no levantara y dara un error (logico, no?)


Más información:
http://blog.acostasite.com/2014/04/solucion-tres-errores-cuando-queremos.html

Configurando Quagga para manipular prefijos (Local Preference) utilizando RPKI

Objetivo:
   En el siguiente mini laboratorio configuraremos Quagga para manipular prefijos BGP y asignar Local Preference segun el estado RPKI (valid, invalid, Not Found).
 
Escenario:
- R1 publica un prefijo con un AS que no le corresponde (segun ROA)
- R2 publica el mismo prefijo que R1 pero desde un AS que si es valido
- R2 publica un prefijo sin ROA.
- En este escenario el validador y el router Quagga estan en el mismo equipo

Diagrama del laboratorio:

Requisitos:
- Quagga con soporte para RPKI
- RPKI Validator de RIPE NCC
- Un prefijo que sepamos que se tiene ROA valido. En nuestro caso utilizamos el prefijo 200.85.64.0 que sabiamos que tiene un ROA que indica que debe ser publicado por el AS 7908
- Ejecutar el validador de RIPE NCC antes de ejecutar Quagga


Configuraciones de todos los equipos

Conf-Quagga-RPKI-Mini-LAB.txt

hostname RPKI-RTR
password test
!
router bgp 65000
 bgp router-id 10.0.0.10
 bgp bestpath prefix-validate allow-invalid
 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 route-map rpki in
 neighbor 10.0.0.2 remote-as 7908
 neighbor 10.0.0.2 route-map rpki in
 neighbor 10.0.0.3 remote-as 65003
 neighbor 10.0.0.3 route-map rpki in
!
route-map rpki permit 10
 match rpki invalid
 set local-preference 10
!
route-map rpki permit 20
 match rpki valid
 set local-preference 30
!
route-map rpki permit 30
 match rpki notfound
 set local-preference 20
!        
line vty
!
enable-rpki
  rpki polling_period 1000
  rpki timeout -1216757171
!
  rpki group 1
    rpki cache 127.0.0.1 8282
! 

R1.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
enable password test
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.1 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 password test
 login
!
end

R2.cfg

!
!
!
!
hostname R2
!
no ip domain lookup
no ip icmp rate-limit unreachable
ip tcp synwait 5
!
!
interface Ethernet0
 ip address 10.0.0.2 255.255.255.0
 half-duplex
!
!
router bgp 7908
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
!
line con 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
line aux 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
!
!
end

R3.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.3 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65003
 no synchronization
 bgp log-neighbor-changes
 network 192.168.0.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 192.168.0.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
end

Salida final en Quagga:
(Notese los flags N, I, V) (Notese los local preference)

RPKI-RTR# sh ip bgp
BGP table version is 0, local router ID is 10.0.0.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
N*> 192.168.0.0      10.0.0.3                 0     20      0 65003 i
I*  200.85.64.0      10.0.0.1                 0     10      0 65001 i
V*>                  10.0.0.2                 0     30      0 7908 i

Total number of prefixes 2

Paso a paso. Instalando Quagga con soporte RPKI

(realizado en Ubuntu 13.04)
1) Instalar varios aplicativos & librerias necesarias:
#apt-get install autoconf
#apt-get install libtool  (es necesario el libtoolize)
#apt-get install gawk  (con solo awk no funciona)
#apt-get install libssh-dev  (libssh es necesario para RPKI)
#apt-get install libreadline-dev  (es necesario para vtysh de quagga)
#apt-get install texti2html
#apt-get install texinfo
#apt-get install cmake
#apt-get install doxygen
#apt-get install build-essential
#apt-get install git


2) Es necesario instalar RTRLIB para tener RPKI en Quagga:
#cd /usr/src
#wget https://github.com/rtrlib/rtrlib/archive/v0.2.3.tar.gz
#tar -zxvf v0.2.3.tar.gz
#cd rtrlib-0.2.3/
#cmake -D CMAKE_BUILD_TYPE=Release -D LIBSSH_LIBRARY=/usr/lib/i386-linux-gnu/libssh.so -D LIBSSH_INCLUDE=/usr/lib/i386-linux-gnu .
#make
#make install

3) Instalar Quagga con soporte RPKI:
#adduser quagga (quagga correra con este usuario)
#cd /usr/src
#git clone git://github.com/rtrlib/quagga-rtrlib.git
#cd quagga-rtrlib/
#./bootstrap.sh  (this will create the configure file)
#./configure --enable-vtysh --enable-rpki   --disable-zebra  --localstatedir=/usr/local/etc
#make
#make install

Hay que decirle al sistema operativo como conseguir RTRlib
#echo "/usr/local/lib/i386-linux-gnu" >> /etc/ld.so.conf
(la linea de arriba depende de la arquitectura)
#ldconfig

Los permisos para el directorio de quagga
#cd /usr/local
#chown -R quagga.quagga etc/

4) Una micro configuracin de BGP para probar que todo levante:
#echo "password test" > /usr/local/etc/bgpd.conf

5) Probar si todo funciona (al menos BGP)
#cd/usr/local/sbin
#./bgpd &
#ps -ef | grep bgpd
#telnet localhost bgpd  (deberias obtener un prompt, password test)

IPv6, no te vistas que no vas. Ahora IPv4S

Netland, Diciembre 2013
  Luego de una reunion casi secreta de una semana en Suiza, los principales fabricantes de hardware y software a nivel mundial tomaron la drástica decisión de no continuar con el desarrollo e implementación de IPv6. Como alternativa decidieron de manera únanime utilizar el mismo protocolo IPv4 y crear un nuevo concepto de sub-IP (IPv4S).
  Los detalles técnicos se describieron así: "Vamos a utilizar un bit que se encuentra reservado en la cabecera IPv4 desde su origen (RFC 791), dicho bit al estar encendido los hosts leeran los campos de datos indicando más direcciones IPv4, es decir, es un subgrupo de IPv4". Según el PhD Tniv Frec: "Esto es algo que debió hacerse hace mucho".
  A la reunión asistieron en gran cantidad los mejores programadores del mundo los cuales se mostraban muy contentos con esta nueva idea. Ms Avaj, una reconocida en programadora orientada a objetos indicó "Al fin", esto es lo que todos necesitamos, ahora el desarrollo de software será tres veces más rápido.
  Con la nueva metodología los fabricantes de hardware y software pueden realizar los ajustes pertinentes de manera más sencilla, rápida y funcional. Para los ISPs y programadores este cambio será transparente debido que ahora cuentan con "SP&P" (Super Plug & Play) donde servidores Web y Mail se autoconfigurarán de manera mágica; Ms Cin indicó que incluso los registros DNS serán realizados sin intervención humana gracias el nuevo registro SeIP (sub enhance IP) donde todos los host hablan con todos los DNSs (full mesh).
  Otro participante lllamado Pir, indica que si esto hubiese existido hace 5 años el Internet actual fuera 400 veces más grande y según Mr. Lrep unas 8 veces rápido.
  Desde el aspecto social, Ms. Locotorp, menciona que esta nueva versión servirá para disminuir el hambre en el mundo gracias a que es un protocolo pensado en el consumo eléctrico, indica que es 34% más eficiente gracias a su inteligencia incorporada, todo gracias al nuevo bit que nadie había querido usar. Al final de la entrevista dió a atender que es una verguenza que ingenieros de todo el mundo no hubiesen hecho esto años atrás.
  Un entrevistado de apellidos Tan Tap que no quiso salir a la luz pública lamenta que IPv6 no hubiese crecido más, indicó que el mal uso del NAT y la gran cantidad de mecanismos de transición le quitaron el impulso a la implementación de IPv6, nuestro reportero indica que Mr Tan Tap siempre tuvo una sonrisa fingida y se rió de todos los que habían implementado IPv6.
  Referente a las redes internas, en base a la información de este grandioso bit, dependiendo de si esta completamente encendido o solo un poco se auto-determina si la dirección IP es interna o externa, a su vez reconoce si el host está en una MZ o DMZ, y simultaneamente aplica las políticas de seguridad pertinentes, los administradores de red no tienen necesidad de modificar ninguna política.
  Mr. Lufetats indica que apoyándose en IPv4S los firewall serán muy sencillos de implementar, unicamente es necesario colocarlo y voila!.., BCP 38, servicios y otras politicas se autoconfiguran.
  Finalmente, dieron a conocer que los conceptos de EGPs e IGPs desaparecerán en unos años. La nueva versión puede hablar inter-AS e  intra-AS gracias a sus mecanismos de reconocimiento de rutas, se adapta de Distance Vector a Link State automaticamente según convenga, reconoce saturación de los enlaces, delay, pérdida de paquetes y comprime los datos cuando es necesario. Incluso percibe cuando el CPU del enrutador está sobre cargado y toma acciones correctivas.
  Estiman que en solo un año todos los hosts de internet contaran con IPv4S, luego, las capas 4 y 7 del modelo OSI desapareceran porque IPv4S puede a su vez llevar directamente los protocolos de aplicación, con ello se espera que la enseñanza de redes sea trivial.


Saludos,

Att.
Rebif Citpo VI

Resumen de FLIP6 en Medellin 2013

Hola todos,
    Es un honor para mi escribir en esta ocasión y compartir mis
impresiones de la 11va. edición del FLIP6 (Foro Latino Americano de
IPv6) en la ciudad de Medellin - Colombia durante los días 7 y 9 de
Mayo de 2013.

    Cada evento es un desafío. es un reto nuevo; cosas inesperadas pueden
ocurrir, tanto cosas buenas como cosas malas. Lo  importante es saber
manejar las situaciones, poderlas llevar y eventualmente poder
superarlas. Tuvimos un gran evento, tanto en el especto técnico,
académico y social.

    Antes de entrar de lleno en el resumen del evento, deseo mencionar que
cuando en la vida se presentan situaciones complicadas no hay que
colocar mala cara y mucho menos rendirse, todo lo contrario, hay que
saber canalizar las preocupaciones y angustias en energía y
entusiasmo, esta es la única manera para poder salir adelante.
Recientemente me enteré que Thomas Alva Edison tenía problemas
auditivos, él, en vez de quejarse decía que menos mal, con ello podía
concentrarse más en sus inventos

Resumen del evento:
Antes de cada evento siempre existe un grado de preocupación, las
preocupaciones van desde “ójala no falte ningún speaker”, que el salón
este lleno y que ójala tengamos tiempo para la agenda completa. Me
complace indicar que en esta oportunidad -igual que las anteriores- el
Foro fue un éxito total y hemos salido aún con más fuerza para seguir
trabajando por la promoción de IPv6 en Latinoamérica y Caribe.

El evento tuvo una duración de casi 7 horas dividido en dos días. Por
primera vez compartirmos un espacio de 3 horas con LACSEC, el objetivo
era unir en la agenda aquellas presentaciones con contenido de
seguridad e IPv6. Más adelante les doy los detalles.

Se contó con la asistencia de unas 400 personas en total, que se apreciaba con
el salón lleno en todo momento. Existen muchos puntos a destacar en
esta oportunidad:

- El cumplimiento de los horarios de los ponentes fue excepcional.
- Cantidad de preguntas realizadas
- El evento estuvo acompañado por una gran difusión vía Twitter,
Facebooks y listas de correo.
- Calidad de los expositores
- Temas novedosos en el foro

    Como siempre, hay que destacar al comité evaluador de LACTF quienes tuvieron la
importante labor de seleccionar los trabajos presentados en la 11va.
edición del FLIP6. Sin el comité el evento no sería lo mismo. Es
sensacional los estudios y charlas que existen tras bastidores para
seleccionar los temas.

    A continuación un breve resumen de cada una de las ponencias:

- Evaluación de la seguridad y diagnóstico de problemas en redes IPv6
- Fernando Gont

    Fernando tuvo la oportunidad de abrir FLIP6, con su tradicional estilo
de exposición: sencillo pero con un alto contenido de nivel técnico
expuso una combinación muy llamativa del toolkit de seguridad de IPv6
y problemas existentes en el área. Vale la pena volver a ver.

- El caso de negocio para IPv6 - Mark Townsley, Cisco.
     Nuestra presentación Keynote vino dada por el Ing. Mark Townsley,
quien es co-chair del WG Homenet de la IETF y además fellow de Cisco.
Expuso un tema sumamente interesante y necesario: “El caso de negocio
para IPv6”. Su presentación fue dinámica y amena, una vez más quedó
expresado porque es importante la implementación de IPv6. Es una
exposición cuya láminas sin duda muchos de nosotros volveremos a
revisar.

- Conexión a Internet IPv6 de redes corporativas - Álvaro Retana, Cisco.
      El Ing Alvaro Retana (Ing distinguido de Cisco) realizó una
presentación de mucho impacto sobre las posibilidades, modalidades y
alternativas de las conexiones a Internet IPv6 en redes corporativas.
Muy interesante, gracias por compartir esta información. Esperemos que
crezca significativamente el sector corporativo en su implementación
de IPv6 en los próximos años.

- Mejores prácticas en nubes públicas para garantizar su seguridad,
respaldo y alta disponibilidad - Efraín Soler, CEO de O4IT.
       Efarin Soler realizó una exposición sobre la plataforma,
tecnología implementada, marco de seguridad y la sencilla interfaz Web
que O4IT tiene para ofrecer. Sin duda alguna muchos de los asistentes
apredimos de este prestigioso sponsor.

- Actualización sobre IPv6 en redes de Gobierno - Jordi Palet, Consulintel.
      Jordi, con su acostumbrado estilo de enseñar y transmitir
información brindó un rápido repaso pero muy importante sobre los
avances en la implementación en algunos países y gobiernos. Mil
gracias por compartir esta información con nosotros. Te esperamos para
que compartas nuevos avances.

- Casos de éxito en implementaciones de IPv6. Evandro Varonil,
Guillermo Cicileo.
      Los Ingenieros Evandro Varonil y Guillermo Cicileo
expusieron muy vividamente sus experiencias implementando IPv6 en sus
organizaciones. Desde FLIP6 estamos muy agradecidos por compartir este
contenido debido a que el mismo ayuda a los interesados que aún  no lo
han hecho a prever algunas situaciones.

- Mobile IPv6 Test Bed: una implementación actualizada - Sebastián
Tobar y Cristian Pérez Monte, Grupo UTN GridTICS (AR)
      Sebastian Tobas y Cristian Perez Monte realizaron una
llamativa exposición sobre IPv6 y movilidad. La ponencia fue muy
ilustrativa y decarácterr novedoso. Ojalá tengamos la oportunidad de
conocer los avances en los próximos meses y/o años.


- Análisis de las técnicas de transición para un mundo sin IPv4 -
Rodrigo Regis dos Santos, NIC.br.
      El Ing. Rodrigo Regis dos Santos realizó una exposición muy
completa cubriendo la mayoría los métodos de transición puntualizando
muy bien las ventajas y desventajas de cada uno de ellos.
¡Muchas gracias por una presentación tan agradable!

- Consideraciones operativas sobre planificación y despliegue de IPv6
- Álvaro Retana, Cisco
     Alvaro Retana le tocó aperturar el estreno en el espacio
compartido de LACSEC/FLIP6. Una vez más realizó una fantástica
presentación sobre las consideraciones operativas durante el
despliegue de IPv6, hizo mucho énfasis en la planificación. Fue
probablemente unas de las presentaciones con mayor participación de
los asistentes, Hubo al menos una hora de preguntas, respuestas y
comentarios luego de finalizar la ponencia. Ojala podamos repetir esta
experiencia.

- Avances recientes en seguridad de IPv6 - Fernando Gont, SI6 Networks.
    Fernando Gont, por segunda vez durante FLIP6 de 2013 conversó sobre
IPv6 y la seguridad, dejando como moraleja que las implementaciones de
este protocolo a su vez deben venir acompañado de políticas de
seguridad, existen problemas que son similares a IPv4 y otros que son
únicamente de IPv6. Ojala contemos con Fernando Gont en futuras
reuniones de FLIP6.


Conclusión:
  Para concluir, tuvimos otra edición de FLIP6 inolvidable, una vez más
intentamos empujar difundir már IPv6 en los asistentes. Después de
cada evento nos despedimos con la intención de que regresen a sus
casas y oficinas con el objetivo de implementar IPv6. Una vez escuché:
“IPv6 is not optional anymore, it’s a must.” (IPv6 ya no es opcional,
es obligatorio)

Para finalizar una pequeña cita para que siga la evolución informática
y con ello IPv6:

 “El verdadero progreso es el que pone la tecnología al alcance de todos.”
— Henry Ford



Att.
Alejandro Acosta
Chair LACTF/FLIP6 2013
http://aaaa.acostasite.com
Twitter: @lactf

Comics + Humor + IPv6

[Chiste]. En caso de emergencia romper el vidrio. ¡Cable de consola adentro!

wetheitteam.com

Publicar prefijos IPv4 sobre una sesión eBGP IPv6

Situación:
  Deseo publicar redes/prefijos IPv4 sobre una sesión eBGP en IPv6

Historia:
  A pesar de no ser común este caso pueden ocurrir en algunas situaciones.

Solución:
  Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6/IPv4). Por ello es posible intercambiar información IPv4 dentro de una sesión eBGP IPv6.

Configuración:
  En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R2 lo aprenda R1).


R1:
!
interface Ethernet0
 ip address 22.22.22.21 255.255.255.252
  ipv6 address 2001:DB8::1/64
!        
router bgp 1
 bgp log-neighbor-changes
 neighbor 2001:DB8::2 remote-as 2
 neighbor 2001:DB8::2 ebgp-multihop 3
 !       
 address-family ipv4
 neighbor 2001:DB8::2 activate
 neighbor 2001:DB8::2 route-map IPv4 in
 no auto-summary
 no synchronization
 exit-address-family

!      
route-map IPv4 permit 5
 set ip next-hop 22.22.22.22
! 
R2:
!
 interface Ethernet0
 ip address 22.22.22.22 255.255.255.252
 half-duplex
 ipv6 address 2001:DB8::2/64
!
router bgp 2
 bgp log-neighbor-changes
 neighbor 2001:DB8::1 remote-as 1
 neighbor 2001:DB8::1 ebgp-multihop 3
 !       
 address-family ipv4
 neighbor 2001:DB8::1 activate
 no auto-summary
 no synchronization
 network 2.2.2.0 mask 255.255.255.0
 exit-address-family
!        

 








"El truco":
  * La sesión eBGP debe ser obligatoriamente multihop, sino, R1 no aprenderá la ruta. Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!). 
  * En R1 quien aprende la ruta debe tener un route-map aplicado cuando aprende las mismas (in) forzando el next-hop con la dirección IPv4 de R2

Mas información:
- http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-2mt/ip6-mptcl-bgp.html#GUID-06407EF3-4FAD-4519-A2A9-6CC6037288C0
- Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco




Espero sea útil!

Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco

Situación:
  Deseo publicar redes/prefijos IPv6 sobre una sesión eBGP en IPv4

Historia:
  A pesar de no ser común este caso pueden ocurrir en algunas situaciones. En esta oportunidad, tengo un router Cisco con soporte IPv6 (routing) pero su configuración BGP no permite definir neighbors IPv6

Error:
  Mensaje que quizás estas recibiendo y el mismo te trajo a esta página  :)

*Mar  1 02:05:00.663: BGP: 1.1.1.1 Advertised Nexthop ::FFFF:1.1.1.1: Non-local or Nexthop and peer Not on same interface
*Mar  1 02:05:00.663: BGP(1): 1.1.1.1 rcv UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, originator 0.0.0.0, path 1, community , extended community
*Mar  1 02:05:00.667: BGP(1): 1.1.1.1 rcv UPDATE about 2001:db8::/32 -- DENIED due to:
*Mar  1 02:05:00.667: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar  1 02:05:00.771: BGP(0): 1.1.1.1 computing updates, afi 0, neighbor version 0, table version 25, starting at 0.0.0.0

Solución:
  Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6). Por ello es posible intercambiar información IPv6 dentro de una sesión eBGP IPv4.

Configuración:
  En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R1 lo aprenda R2).


R1:
!
 interface Ethernet1/0
 ip address 1.1.1.2 255.255.255.252
 full-duplex
 ipv6 address 2001:db8::1/64
 ipv6 enable
!
router bgp 1
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 1.1.1.2 remote-as 2
 neighbor 1.1.1.2 ebgp-multihop 2
 no auto-summary
 !
 address-family ipv6
 neighbor 1.1.1.2 activate
 network 2001:db8::/32
 no synchronization
 redistribute static
 exit-address-family
!
ipv6 route 2001:db8::/32 Null0


R2:
!
 interface Ethernet1/0
 ip address 1.1.1.2 255.255.255.252
 full-duplex
 ipv6 address 2001:db8::2/64
 ipv6 enable
!
router bgp 2
 no synchronization
 bgp router-id 1.1.1.2
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 ebgp-multihop 2
 no auto-summary
 !
 address-family ipv6
 neighbor 1.1.1.1 activate
 neighbor 1.1.1.1 route-map IPv6-NextHop in
 exit-address-family
!
route-map IPv6-NextHop permit 10
 set ipv6 next-hop 2001:db8::1
!

"El truco":
  * La sesión eBGP debe ser obligatoriamente multihop, sino, R2 no aprenderá la ruta (el mismo error que se ve arriba). Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!). 
  * En R2 quien aprende la ruta debe haber un route-map aplicado cuando aprende las rutas (in) forzando el next-hop con la dirección IPv6 de R1

Después de aplicar ebgp-multihop (todo funciona):

*Mar  1 02:01:42.539: BGP(1): 1.1.1.1 rcvd UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, path 1
*Mar  1 02:01:42.539: BGP(1): 1.1.1.1 rcvd 2800:26::/32
*Mar  1 02:01:42.543: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar  1 02:01:42.543: BGP(1): Revise route installing 2001:db8::/32 -> 2001:db8::1 (::) to main IPv6 table

Mas información:
- https://supportforums.cisco.com/docs/DOC-21110
- http://ieoc.com/forums/p/15154/130174.aspx
- http://ieoc.com/forums/p/15154/130174.aspx


Espero sea útil!

Convertir un Access point Cisco Aironet 1242 modo Lightweigth a Access point modo Autónomo/Stand Alone

Situacion:

La mayoría de estos equipos Cisco Aironet vienen con la IOS (Internetwork Operating System) para que funcione en modo Lightweigth y por más que trates de configurarlos por cualquier vía no lo vas a poder hacer si no tienes un WLC (Wireless Lan Controller) los cuales son algo costosos.

El problema de los Access Point (AP)  en modo Lighweigth es que toman la configuración del WLC (Wireless Lan Controller) que esté presente en la red, por esto estos AP se les conoce como zero touch debido a que no hace falta realizarle casi  ninguna configuración. En resumen si no tenemos un WLC no podremos configurar el AP vía web ni vía consola.

Si ingresas vía consola (Hiperterminal u otro) te va a pedir la contraseña de modo privilegiado la cual por defecto es “Cisco” después de eso cuando intentes pasar a modo global ejecutando el comando “configure terminal” como en el cualquier dispositivo CISCO te aparecerá el siguiente mensaje ”command not found”, yo también me preocupé en ese momento pensé que el dispositivo tenía algún tipo de problema, ejecuté cualquier cantidad de comandos existentes para pasar a modo de configuración pero nada.

Intenté conectarme vía web, por defecto el AP viene con la dirección 10.0.0.1 simplemente lo conecte mediante su puerto  Ethernet a mi computadora a la cual le asigne la dirección 10.0.0.2, probé la conectividad con el comando ping entre ellos y todo estaba perfecto pero en el momento de intentaba ingresar vía web (mediante un explorador de internet e.g Internet Explorer ,Mozilla Firefox ,colocaba la dirección 10.0.0.1) no me dejaba ,simplemente es que en el modo Lightweight no tenemos acceso al AP vía web.

La solución:

La solución es cambiarle la IOS al AP para que este funcione en modo Autónomo o Stand Alone en vez de Lightweight y así poder configurar el AP normalmente ya sea vía Web o mediante consola.

Procedimiento:

Los siguientes son los pasos para revertir un AP que esta en modo LWAPP a modo Autónomo cargando un Cisco IOS utilizando un servidor TFTP.

1.- En nuestra PC cargamos un servidor TFTP en esta misma maquina configuraremos el AP.

2.- El PC se comportara como el servidor TFTP le asignaremos por ejemplo la dirección 10.0.0.2 (acordémonos que el AP por defecto tiene la 10.0.0.1)al mismo tiempo nos conectamos mediante el cable de consola al AP mediante la aplicación Hiperterminal.

3.- Después que conseguimos la nueva IOS (c1240-k9w7-tar.default) la copiamos  a la carpeta donde guarda el servidor TFTP los archivos por defecto. (debemos que asegurarnos de que tenemos la nueva IOS en el PC que esta  como servidor TFTP)

4.- El siguiente paso simplemente es conectar el AP a nuestro PC (servidor TFTP) mediante un cable utp.

5.- Desconecte el AP de la corriente eléctrica.

6.- Conectamos el AP a la corriente eléctrica al mismo tiempo que mantenemos presionado  el botón MODE en el AP.

7.- Esto lo hacemos alrededor de 20 a 30 segundos el LED de AP se coloca de color lila, como tenemos abierta la aplicación  Hiperterminal en ella nos debería aparecer el siguiente mensaje “button is pressed ,wait for button to be released…”

8.- En este momento la nueva IOS se esta copiando desde el servidor TFTP a la flash del AP, simplemente debemos esperar a que se termine de copiar.

9.- Automáticamente la nueva IOS reemplazara a la anterior.

10.- Lo único que nos queda es por fin empezar a configurar nuestro AP ya sea vía consola o vía web.

Nota: para conseguir la IOS que necesitamos solo debemos colocar  en google lo siguiente        “ c1240-k9w7-tar.default shared “   abrimos el primer resultado que nos arroje, y la descargamos.

Nota: para poder ingresar vía web al AP este necesita tener configurado una dirección ip, además de un usuario con nivel 15 de privilegio, lo creamos de la siguiente manera:

AP (config) username “nombre usuario” privilege 15 password “password”.

Nota: para descargar el servidor TFTP simplemente hazlo desde esta página http://www.winagents.com/en/downloads/download-tftp-server.php.

1.-Le colocamos nombre al AP

Router (config)hostname AP

2.-Configuramos un SSID al AP podemos tener varios SSID.(por ejemplo le colocamos WIRELESS)

AP (config)dot11 ssid WIRELESS

AP (config-ssid)authentication open 

AP (config-ssid)infraestructura ssid

AP (config-ssid) guest mode     (el AP divulgara el SSID para que los clientes lo puedan ver)

AP (config-ssid) authentication key management wpa versión 2(opcional le configuramos el protocolo WPA versión 2 para la forma en que administrara las claves)

AP (config-ssid)wpa-psk  ascii “clave”(definimos la contraseña para que los clientes puedan conectarse al AP)

El AP posee 2 interfaces dot11radio0 (2.4 GHz) y dot11radio1 ( 5 GHz)

3.-Asociamos el SSID a la interface a cual queremos que los clientes se conecten.

Interface Dot11radio0

AP (config-if) ssid WIRELESS

AP (config-if) station-role root (por defecto viene así)

AP (config-if) encryption mode ciphers aes-ccm (opcional, definimos AES como el algoritmo de encriptamiento)

AP (config-if) no shutdown (levantamos la interface)

4.-Le asignamos una ip al AP estáticamente para administración (por ejemplo 192.168.1.1) o si existe un servidor DHCP simplemente dejamos que el AP  reciba un IP del mismo.

(config) interface BVI 1

(config-if) ip address 192.168.1.1 255.255.255.0

(config-if) no shutdown

Procedimiento realizado por:  @AlejandroFerrer

Crucigrama IPv6

http://goo.gl/lVuv6

Espero les guste!....

DNS64 y NAT64 paso a paso con explicación

Introducción:
DNS64 y NAT64 son dos tecnología diferentes que comunmente trabajan en conjunto.

DNS64 y NAT64 es ideal para colocar en el borde una red donde unicamente existan host con IPv6, algo cada día es más común sobre todo en el mundo de redes celulares y se gran cantidad de sensores.

En Internet hay mucha información sobre como configurar NAT64 y DNS64, la mayoría dice que muy fácil, otros lo colocan más complicado. En lo personal no conseguí ninguna que explicara paso a paso como hacerlo y adicionalmente que explicara la topología de red donde se estaba configurando.

En este post comienzo instalando DNS64 y luego procedemos con NAT64. Se puede instalar en cualquier orden.

Que se necesita antes de comenzar:

- Una subred IPv6 libre (una /96 esta bien) para realizar el mapeo DNS entre IPv4 e IPv6. Esta misma subred la utilizaremos dentro de Tayga para el NAT64

- Logicamente conectividad IPv6 entre los clientes y el servidor DNS64 y NAT64 (no se requiere IPv4)



Topología:
a) Servidor realizando. Solo tiene una interfaz (eth1)

IPv6: 2001:db8:1:1::/64 (eth1).
IPv4: 192.168.124.107

b) IP de un cliente (eth2):

2001:db8:1:1::2/64


c) Subredes IPv6:

Red que "retorna" el DNS64 2001:db8:1:ffff::/96
Pool de NAT en el NAT64: 2001:db8:1:ffff::/96

(si, son el mismo bloque)


d) Interfaz dns64:

192.168.124.107/32
2001:db8:1::1/128


(correcto!, la IPv6 e IPv4 de eth1 se solapan con interfaz dns64)



Procedimiento de DNS64.

Paso 1:

Instalar BIND9:

#aptitude install bind9


Paso 2:

Configurar /etc/bind/named.conf.options:

a) Asegurar que BIND escuche en IPv6 (recordemos que los clientes van a estar en IPv6)

listen-on-v6 { any; };

b) Permitir consultas desde cualquier IP. Si estas utilizando un servidor público o en producción favor restringir las consultas a tus clientes

allow-query { any; };

c) Realizar el DNS64 con la siguiente directiva.

dns64 2001:db8:1:ffff::/96 { 
    clients { 
      any; };
 };

La configuración del punto "c" lo que indica es que aquellas consultas DNS de aquellos registros que SOLO tienen tienen registro A (no tienen registro AAAA) serán entregadas a los clientes añadiendo 2001:db8::1:ffff::/96


d) Reiniciar bind9

#/etc.init.d/bind9 restart


Probar DNS64:

a) En un PC cliente colocar como servidor DNS: 2001:db8:1:1::1


b) Ubicarse en un cliente y realizar consultar DNS de hosts solo con direcciones IPv4 (registros A). Por ejemplo:


root@ubuntu-VirtualBox:~# dig ipv4.google.com aaaa @2001:db8:1:1::1

; <<>> DiG 9.8.0-P4 <<>> ipv4.google.com aaaa @2001:db8:1:1::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 64252="64252" br="br" id:="id:" noerror="noerror" opcode:="opcode:" query="query" status:="status:">;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;ipv4.google.com.               IN      AAAA

;; ANSWER SECTION:
ipv4.google.com.        0       IN      CNAME   ipv4.l.google.com.
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8268
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8269
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:826a
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8293
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8263
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8267

;; AUTHORITY SECTION:
google.com.             171975  IN      NS      ns1.google.com.
google.com.             171975  IN      NS      ns4.google.com.
google.com.             171975  IN      NS      ns2.google.com.
google.com.             171975  IN      NS      ns3.google.com.

;; Query time: 219 msec
;; SERVER: 2001:db8:1:1::1#53(2001:db8:1:1::1)
;; WHEN: Wed Jan  2 16:11:57 2013
;; MSG SIZE  rcvd: 294



Nota: La parte a destacar en esta salida son las direcciones IPv6 que comienzan por: 2001:db8:1:ffff..., ya en este momento sabemos que DNS64 esta funcionando.



Ahora NAT64

1) Utilizamos Tayga. El sitio oficial y link para descargarlo se encuentra en: http://www.litech.org/tayga/


2) Lo descomprimimos y desempaquetamos:

#tar -jxvf tayga-0.9.2.tar.bz2
#cd tayga-0.9.2
#./configure
#make
#make install

3) Creamos el directorio donde Tayga guardará los logs:

#mkdir /var/log/tayga

4) Editamos el archivo /usr/local/etc/tayga.conf

y copiamos y pegamos:

tun-device nat64
ipv4-addr 192.168.255.1
prefix 2001:db8:1:ffff::/96
dynamic-pool 192.168.255.0/24
data-dir /var/log/tayga


Tayga es stateless y realiza un nat 1:1 entre IPv6 e IPv4. En la configuración anterior a cada cliente IPv6 se le asignará un IP del pool 192.168.255.0/24; por ello si tenemos más de 255 hosts será necesario utililzar un pool más grande que /24. En caso de que tengas IPv4 públicas suficientes puede ser útil para evitar un doble NAT IPv4.

La directiva prefix indica el prefijo que utilizará Tayga para reconocer los 32 bits de IPv4, es decir, cuando el destino IPv6 sea: 2001:db8:1:ffff::/96, Tayga tomará los ultimos 32 bits para reconocer que ese es el destino IPv4

5) Habilitar routing IPv6 e IPv4 en el servidor.

#echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
#echo "1" > /proc/sys/net/ipv4/ip_forward

6) Creación y configuración de la interfaz nat64:

#tayga --mktun
#ip link set nat64 up
#ip addr add 192.168.124.107 dev nat64
#ip addr add 2001:db8:1::1 dev nat64

(estos comandos crean la interfaz nat64 con las direcciones ip 192.168.0.1/32 y 2001:db8:1::1/128, como dije anteriormente no importa que se solape con los IPs de eth1).

Para revisar:
root@aacosta-ThinkPad-E420:~# ifconfig nat64
nat64     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.0.1  P-t-P:192.168.0.1  Mask:255.255.255.255
          inet6 addr: 2001:db8:1::1/128 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2393 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2395 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:1615556 (1.6 MB)  TX bytes:1614316 (1.6 MB)

7) Creación de rutas:
#ip route add 192.168.255.0/24 dev nat64
#ip route add 2001:db8:1:ffff::/96 dev nat64

8) Ejecutamos Tayga

#tayga -d

(el -d es opcional, solo es para tener más información)


PROBAR NAT64
a) Probamos que todo este bien (el ping debe ser satisfactorio):

root@aacosta-ThinkPad-E420:~# ping6 2001:db8:1:ffff::192.168.0.1
PING 2001:db8:1:ffff::192.168.0.1(2001:db8:1:ffff::c0a8:1) 56 data bytes
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=109 ttl=63 time=2.18 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=110 ttl=63 time=0.209 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=111 ttl=63 time=0.190 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=112 ttl=63 time=0.126 ms


b) Realizamos NAT con la interfaz IPv4 saliente (solo si el pool IPv4 en Tayga es privado):

#iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 
#iptables -A FORWARD -i eth0 -o nat64 -m state --state RELATED,ESTABLISHED -j ACCEPT 
#iptables -A FORWARD -i nat64 -o eth0 -j ACCEPT

c) Ahora solo debes dirigirte a la máquina cliente y todo debe estar funcionando. Ejemplos de ping y trace:


[root@localhost ~]# traceroute6 www.algo.com -n
traceroute to algo-com-prod-elb-170663297.us-east-1.elb.amazonaws.com (2001:db8:1:ffff::36f3:7ac3) from 2001:db8:1:1::2, 30 hops max, 16 byte packets
 1  2001:db8:1:1::1  1.224 ms  3.8 ms  0.352 ms
 2  2001:db8:1:ffff::c0a8:ff01  0.787 ms  0.772 ms  0.268 ms
 3  2001:db8:1:ffff::c0a8:1  0.76 ms  0.869 ms  0.278 ms

[root@localhost ~]# ping6 www.parmalat.com.ve -n
PING www.parmalat.com.ve(2001:db8:1:ffff::c82f:4f04) 56 data bytes
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=1 ttl=56 time=7.30 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=2 ttl=56 time=5.82 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=3 ttl=56 time=5.93 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=4 ttl=56 time=8.38 ms


  Puedes ver un estado de las asignaciones de Tayga en: /var/log/tayga/dynamic.map



Voila!... todo debe estar funcionado en este momento!


Mas información: 
http://www.litech.org/tayga/
http://www.litech.org/tayga/README-0.9.2

http://kurser.iha.dk/eit/itifn/workshops/vne_workshop_2.html
http://ipvsix.me/?tag=tayga

Notas importantes:
- El DNS64 no funciona cuando la respuesta DNS tenga registros AAAA y A. En realidad no es una eroor porque se asume que el host tiene acceso IPv6 a Internet
- Es importante que el DNS64 y NAT64 compartan el mismo prefijo IPv6 (en el ejemplo de este post 2001:db8:1:ffff::/96. 
- Durante todo el post describo el procedimiento utilizando la subred IPv6 2001:db8::/32. Favor notar que esta subred debe ser sustituida por sus redes respectivas (al igual que la información referente a IPv4).
- Pueden utilizar 2001:db8::/32 y va a funcionar igualmente pero sin acceso a destinos a IPv6
- El servidor DNS64 y NAT64 pueden ser diferentes equipos/máquinas



to get detailed information about Managed IT Services visit https://wetheitteam.com