Como instalar ipv6 en Red Hat 7.3 en adelante
Siguiendo con mi raconto de experiencias personales para compartir con la comunidad Lugro, les comentaré como se implementa ipv6 en la distro RedHat 7.3 en adelante, con núcleo 2.4.18. Cabe destacar que los núcleos mayores al 2.4.10 soportan en un 100% ipv6 así como algunas aplicaciones ya tienen la posibilidad de conección usando direcciones ipv6 e ipv4, como ser: domain, ssh, apache2, etc. De aqui en más contaré mis experiencias personales en poner a punto una red LAN, como algunos de mis fracasos que no pude resolver, para que alguien descubra porque no anda. Previo a ello introduciré unos conceptos básico.
Si deseas escribirme puedes hacerlo a horacio9573@hotmail.com
Toda dirección ipv6 se expresa
canónicamente en base hexadecimal, cuyas direcciones binarias de
destinos y proviniencia constan de 128 bits, esto permite un total de 2128-1
direciones legítimas. Si lo comparamos con el ipv4 el incremento
es tal que se puede cubrir todo el universo conocido con direciones con
una desidad de 1 dirección cada kilómetro cúbico.
La forma canónica de expresar una dirección ipv6 es en 8
grupos de 16 bits escritos en notación hexadecimal como por ejemplo
3ffe:ffff:0100:f101:0210:a4ff:fee3:9566
Se acepta las siguientes abreviaturas de
escritura
Existen solo dos direcciones resrvadas
en ipv6, una es la dirección local ::1 (se están simplicando
31 ceros), esta solo se la puede asociar al dispositivo "loopback", es
similar en ipv4 a la dirección privada 127.0.0.1, otra es
:: (todo cero) que corresponde a dirección no especificada
y no puede usarse como direción de nada. En cabio no existe la dirección
broadcast, por lo tanto en teoría ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
es legítima, pero no se usa. Otro concepto importante es el
prefijo, este determina una reserva del espacio de direcionamiento de la
dirección para definir la red, la sub-red, etc, etc, por ejemplo
2002::/16 el prefijo es 16 y nos indica que los primeros 16 bits
corresponden a la caraterización de la red.
Las direcciones ipv6 son identificadores
de 128 bits que pueden estar asociados a una interfaz (eth*, sit*,
freenet, lo, etc.) y se las clasifican de la siguiente forma:
Espacio de direccionamiento especial
en ipv6
Este es un resumen
del espacio de direccionamiento especial usado en ipv6 :
Direciones unicast locales
Existen dos tipos de direciones unicast locales, por otro lado todo nodo debe por lo menos contener una de ellas, su formato de dirección es
|
n-bits
| 128-n bits
|
|----------------------------------|------------------------------------|
|
Prefijo de subred | identificador de interfaz
|
El identificador de interfaz se emplea para identificar interfaces en un enlace y deben ser único en dicho enlace. Los dos tipos de direciones locales son: Enlace local (link-local) y sitio (site-local). Las primeras tiene un formato fe80::<id de interfaz>/10 y estan asociadas a una intefaz, y no puden salir de ella ningún paquete que tenga como dirección de destino una de ellas. Algunos ejemplos obtenidos del comando /sbin/ifconfig
fe80::200:21ff:fe43:ca26/10 Scope:Link asociado a una targeta de red, aqui el ID de interfaz es un mapeo del número mac (rfc2464)
fe80::c0a8:204/10 Scope:Link asociado a la interfaz sit1, el ID es un mapeo de la dirección ipv4 de mi máquina 192.168.2.4 escrito en hexadecimal ::c0a8:204 asociada con la targeta de red
fe80::1/10 Scope:Link asociado a la interfaz lo
Las segundas tiene un formato fec0::<id-subred><id-interfaz>/10 y estan asociadas a un sitio u organización, son análogas a las redes privadas 192.162.0.0/16, pero con muchos más espacio de direciones. No pueden salir ni por ruteadore ni por pasrelas los paquetes ipv que lleven ese espacio de direciones. Como ejemplo
fec0::1:200:21ff:fe43:ca26/10 Scope:Site asociada a una targeta de red, cuyo id-subred es :1: a la izquierda del ID 200:21ff:fe43:ca26
fec0::2:2e0:7dff:fed8:82f/10 Scope:Site asociado a otra subred, :2:, del mismo nodo, pero de otra targeta de red.
Direciones AnyCast (rfc 2526)
Tienen el mismo rango que las unicast,
cuando una direción unicast es asociada a más de una interfaz
se convierte en una dirección anycast. Existen direciones anycast
asociadas a cada subred requeridas para los ruteadores (subnet router
anycast address). Su formato es <prefijo de red><subred>::/n
es decir el identificador de interfaz es el cero.
Todos los paquetes que contengan esta
dirección de destino serán enviados a dicha subred por los
routers. Por ejemplo
3ffe:b80:1daf:1::/64 aca 3ffe:b80:1daf es el identificador de la red freenet y :1: corresponde a mi subred. 1daf es el tunel asignado.
Otro ejemplo es este 3ffe:38e1:0100:a001::/64, donde 3ffe::/16 prefijo del 6bone, 3ffe:3800::/24 prefijo de fibertel, 3ffe:38e1::/32 prefijo para la UTN la Plata, 3ffe:38e1:0100::/48 prefijo para la Facultad, y finalemte 3ffe:38e1:0100:a001::/64 prefijo para la subred de la facultad con la posibilidad de 264-1 hosts o interfaces.
fe80::/10 Asociada a toda interfaz local
fec0::/10 Asociada a todo el sitio.
Direciones MultiCast (rfc 2375)
Es una direción que caracteriza a un conjunto de nodos, tiene un formato
| 8 bits
| 4 bits | 4 bits | 112 bits
|
| 11111111 | 000T | ámbito| identificador
de Grupo |
Si el bit T=0 la dirección multicast
es permanente y está designada por la ipv6 global address,
caso contrario su valor es T=1 y se trata de una dirección temporaria.
Los cuatro bits del ámbito tiene el siguiente significado.
| 0 | Reservdo |
| 1 | Ámbito local de Nodo |
| 2 | Ámbito local de Enlace |
| 3 | No asignado |
| 4 | No asignado |
| 5 | Ámbito local de Sitio |
| 6 | No asignado |
| 7 | No asignado |
| 8 | Ámbito local de Organización |
| 9 | No asignado |
| A | No asignado |
| B | No asignado |
| C | No asignado |
| D | No asignado |
| E | Ámbito Global |
| F | Reservado |
El identificador de grupo asocia a un grupo en particular de interfaes, como ejemplo de direcciones
ff01::101 A todos los identificadores
de tiempo (NTS) con identificado de grupo 101 en ambito del nodo
ff02::101 A todos en el mismo enlace
asociado con la misma interfaz con id-grupo 101
ff01::101 idem pero a toda la internet.
ff15::101 No permanente asociada
al sitio. La direcciones temporales tiene solo sentido a nivel local.
Existen direciones multicas reservdas son:
Ejemplos útiles de redes actualmente usadas:
3ffe::/16 red 6bone global
3ffe:ffff:/32 dirección
especial 6bone de prueba
2002::/16 redes para direcciones
tunel 6to4 globales (rfc3056)
Direciones unicast globales anexables (rfc2374)
Uno de los problemas que ipv6
resuleve es la major organización jerárquica del ruteo en
redes publicas anexables (agregable public global net), como
ejemplo de ello es la dirección anycast de la UTN de la plata, 3ffe:38e1:0100:a001::,
comentada con anterioridad. Es una organización basada en tres niveles
| 3 | 13
| 8 | 24
| 16 |
64 |
| FP| TLA-ID| Res.|
NLA-ID| SLA-ID| Interfaz-ID|
|<---Topología---->|<----Topología--->|
|
Pública |
Sitio
|
| FP | Prefijo de Formato (001 ó 3* 2* en hexadecimal ) |
| TLA-ID | Identificador de anexado nivel superior |
| Res. | Reservado. |
| NLA-ID | Identificador de anexado siguiente nivel |
| SLA-ID | Identificador de anexado del sitio |
| Interfaz-ID | Identificador asociado con la interfaz de enlace. |
| Tipo | Prefijo Binario | Prefijo en hexa | Fracción de espacio de direccines |
| Reservado para NSAP | 0000 001 | 02* 03* | 1/128 |
| Reservado para IPX | 0000 010 | 06* 07* | 1/128 |
| Direcciones globales Unicast "aggregatable" | 001 | 2* 3* | 1/8 |
| Didercciones enlcace-local (**) | 1111 1110 10 | fe8* .... feb* | 1/1024 |
| Direcciones enlace-red (**) | 1111 1110 11 | fec* .... fef* | 1/1024 |
| Direcciones Multicast | 1111 1111 | ff* | 1/256 |
Experiencias
Bueno de ahora en más contaré mis experiencias con esto. No espers que sea un experto, asi que espero que me disculpen los técnicos.
Preperando el nucleo:
el núcleo genérico Linux version 2.4.18-3 que viene en la distro RH 7.3 soporta muy bien ipv6, pero se debe pasar algunos parámetros especiales al núcleo para que manipule los paquetes ipv6. Si uno usa un núcleo personalizado y se enfrascó en la configuración casi seguro borró todo el soporte ipv6. Este es un gran defecto a mi enterder que tiene Linux respecto de FreeBSD y OpenBSD, pues uno tiene la opción "make GENERIC' y genera un núcleo genérico de fuentes actualizadas sin tener que apelar a correr "make menuconfig'' o sus equivalentes gráficos y leer complejas ayudas.
Los parámetros los modificaremos usando el comando sysctl (como root) pues es una forma más profecional que usar ``echo 1 > ....'' en el archivo de arranque rc.local, además es un estilo de trabajo universal cuando no se disponga del pseudo directório /proc (como ocurre en *BSD). Para ello basta ingresar:
sysctl -w net.ipv6.conf.all.autoconf=0 sysctl -w net.ipv6.conf.all.accept_ra=0 sysctl -w net.ipv6.conf.all.accept_redirects=0 sysctl -w net.ipv6.conf.all.forwarding=1 sysctl -w net.ipv6.conf.all.router_solicitations=0ó bien pueden escribirse en el archivo /etc/sysctl.conf las instrucciones posteriores al comando (posteriores a "-w") para que se asignen automáticamente en el arranque. Esto permite evitar ciertos problemas cuando se configure ipv6-to-ipv4 y se desee usar freenet (206.123.31.102) como router remoto ipv6 a través del protocolo 41. Esto es conocido como tunel ipv6 ver www.freenet.org.
Advertencia!
El protocolo 41 (ipv6-to-ipv6) no debe ser filtrado por ningún firewall, sino no se podrá comunicar con el router. Entoces uno debe configurar las correctas políticas tanto en el ipchains, iptables, etc. para que nuestra red sea trasparente a él.
Configuración de dispocitivo Ethernet, local y sit
Primero debemos agregar en el archivo /etc/sysconfig/network lo siguiente:
NETWORKING_IPV6=yes IPV6_GATEWAYDEV=sit1pues vamos a usar los scripts que vienen con la distro para automatizar la confiración del soporte de red, y definir como pasarela ipv6 al dispositivo sit1 para luego hacer tunel con el router. En Argentina no existe a mi conocimiento router ipv6 en coneciones dial-up (en adsl no se?)
Si disponemos de una red LAN, como en mi caso, podemos hacer lo siguiente para que el dispositivo "eth*'' use ipv6, sino pasamos al párrafo siguiente. Agregamos lo siguiente en /etc/sysconfig/network-scripts/ifcfg-eth0
IPV6INIT=yes IPV6ADDR=inet6 addr: fec0:0:0:f101::4/64Esta última es una dirección ipv6 asociada a nuestra red local (ver apéndice), pues en ipv6 un dispositivo puede tener más de una dirección, siendo la única importante la de enlace. (ver RFC-2373) Ahora si tenemos accesos a internet y tenemos una ipv4 no privada (rfc1918), por ejemplo 192.88.99.1, se coloca una dirección ipv6-6to4 de alcance global de la forma ``2002:(0xipv4)::1'', donde ``0xipv4'' significa el valor hexadecimal en heptetos de la dirección canónica ipv4. En nuestro caso es ``2002:c058:6301::1'' donde ``c058:6301'' es dicha dirección. El número ``64'' es el prefijo y corresponde al número de bites fijos que determinan mi subred, el resto es varible, lo que permite una subred de 264 máquinas. En ipv6 no existe el concepto de máscara de red. Si dispusiésemos de un tunel a un 6bone (Una troncal ipv6) se usa "3ffe:<prefijos>::1", pero en este último caso los prefijos nos lo asignará nuestro servidor de acceso 6bone cuando nos registremoas, como es el caso de freenet.
Previo a todo debemos configurar nuestro dispositivo "lo" (localhost) para que localmente manipule ipv6, entonces agregamos lo siguiente en /etc/sysconfig/network-scripts/ifcfg-lo
IPV6INIT=yes IPV6ADDR=::1::1 es la dirección reservada al localhost. Y no requiere prefijos.
Bueno ahora hay que configurar el dispositivo "sit1", para ello creamos el archivo /etc/sysconfig/network-scripts/ifcfg-sit1 y le ingresamos lo siguiente: (para que arranque en el booteo cambiar el valor "no" por "yes" en ONBOOT)
DEVICE=sit1 BOOTPROTO=none ONBOOT=no IPV6INIT=yes IPV6TUNNELIPV4=206.123.31.102 IPV6ADDR=3ffe:b00:c18:1fff:0:0:0:7f5/128206.123.31.102 es el ipv4-address de freenet, en cambio 3ffe:b00:c18:1fff:0:0:0:7f5 es el ipv6-address de nuestra máquina y es de alcance global. Aqui el prefijo "128" corresponde a un HOST.
Advertencia:
sit0 no puede usarse para definir nuestro dispositivo tunel, pues este es usado como dispositivo especial.
Si todo estuvo ok, ya podemos usar el script ifup-ipv6 para activar nuestro eth0 (si lo tenemos), lo y sit1. El módulo ipv6.o se cargará automáticamente bajo demanda cuando usemos el script. Si no hubo problemas debemos visualizar los siguientes dispositivo con ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:00:21:43:CA:26 inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fec0:0:0:f101::4/64 Scope:Site inet6 addr: fe80::200:21ff:fe43:ca26/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:21442 errors:0 dropped:0 overruns:0 frame:0 TX packets:19677 errors:0 dropped:0 overruns:0 carrier:0 collisions:422 txqueuelen:100 RX bytes:16613246 (15.8 Mb) TX bytes:2291906 (2.1 Mb) Interrupt:5 Base address:0x320 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:615 errors:0 dropped:0 overruns:0 frame:0 TX packets:615 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:146630 (143.1 Kb) TX bytes:146630 (143.1 Kb) sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)Donde sit0 es el dispositivo especial antes enunciado. Pero esto no es todo, en Rh 7.3 usa el xinetd como superdemonio, este se reeplazará con xinetd-ipv6 automáticamente, para que podamos correr aplicaciones que usen ambos protocolos.
Por ejemplo, en el siguiente listado optenido con "netstat -tan" muestra la existencia de aplicaciones que usan ipv6.
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN tcp 0 0 192.168.1.4:80 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:113 0.0.0.0:* LISTEN tcp 0 0 192.168.1.4:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN tcp 0 0 192.168.1.4:443 0.0.0.0:* LISTEN tcp 0 0 :::21 :::* LISTEN tcp 0 0 :::22 :::* LISTEN tcp 0 0 :::119 :::* LISTEN tcp 0 0 ::1:953 :::* LISTENcomo ser ssh (puerto 22), ndc (puerto 953), leafnode (puerto 119) y ftp (puerto 21) por último colocamos nuestras identidades en el archivo /etc/hosts, por ejemplo en mi caso
127.0.0.1 localhost.localdomain localhost ::1 localhost.ipv6.ar localhost6 192.168.1.4 clara.intranet.ar clara fec0:0:0:f101::4 clara.ipv6.ar clara6 192.168.1.11 oscura.intranet.ar oscura fec0:0:0:f101::11 oscura.ipv6.ar oscura6Bueno ahora para activar el tunel (si uno se conecta con la WAN via dial-up, primaro hay que conectarse ojo!) basta con ingresar
/etc/sysconfig/network-scripts/ifup sit1
si se activó devemos visualizar lo siguiente con el comando ifconfig:
sit1 Link encap:IPv6-in-IPv4 inet6 addr: 3ffe:b00:c18:1fff::7f5/128 Scope:Global inet6 addr: fe80::c82b:3073/10 Scope:Link inet6 addr: fe80::c0a8:104/10 Scope:Link UP POINTOPOINT RUNNING NOARP MTU:1494 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)Y ya estamos tuneleados! Ahora bien lo que nos falta es definir la ruta por defecto de los paquetes, para ello ingresamos
/sbin/ip -6 route add default dev sit1 metric 1
Advertencia:
Si usásemos el servicio dado por freenet, cuando levantemos el servicio, este nos dará una ruta por defecto al dispositivo automáticamente como una dirección 6bone.
esto último lo podemos automatizar en el arranque con el script "rc.local'' , aunque debe existir otra forma no la sé. Si todo anduvo bien caundo ingresemos debemos ping6 a un dominio ipv6 debemos ver como se resuleve el nombre de la siguiente forma.
[root@clara root]# ping6 www.jp.freebsd.org PING www.jp.freebsd.org(3ffe:501:185b:101:2a0:24ff:fe57:e561) 56 data bytes --- www.jp.freebsd.org ping statistics --- 37 packets transmitted, 0 received, 100\% loss, time 36014msAhora bien porque se pierden los paquetes, la razón es que freenet nos obliga a estar registrados para acceder a su servicio, existe una explicacion de como usarlo y obtener la clave de usuarios en http://www.freenet.org, pero lo más importante es que nuestro sistema resolvió el nombre. Ahora bien como lo hizo, pues para ello activé previamente el demonio named y definí como zonas:
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT"
{
type master;
file "localhost.rev";
};
zone "1.0.1.f.0.0.0.0.0.0.0.0.0.c.e.f.ip6.init"
{
type master;
file "clara6.rev";
allow-transfer{none;};
};
acto contrario, no es posible usar resolvedores alternativos de freenet
definidos en el archivo "/etc/resolv.conf'' dadas las restriciones
antes mensionadas. De los dos archivos de zona solo pondré
como ejemplo el requerido para el "localhost", pues es el más universal.
Las instrucciones para la zona local son:
;/var/named/named.local
;traduccio'n inversa para 127.0.0
;El origen es 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT.
$TTL 604800
@ IN SOA
clara.ipv6.ar. root.clara.ipv6.ar. (
2003043001 ;serie
36000 ;refresco por 100 horas
7200 ;reintento por 2 horas
3600000 ;expira en 1000 horas
2419200 );minimo 1 mes
IN
NS clara.ipv6.ar.
1 IN
PTR localhost.
Bueno aca termiana esta receta, este es un texto un poco incompleto, pero es una version por ahora alfa, en el futuro lo haré mejor.
Saludos Horacio