IPv6 Ya es el presente y futuro de Internet
Buscando en el baul de los recuerdos (uuuuuh) encontré un artículo que escribí en el extinto e-zine «#NetSearch» en septiembre del 99, hace casi 12 años, sobre IPv6. Algunas de las cosas del documento han cambiado, sobre todo el apartado en el que señalaba que eran DRAFTs (Borradores), pero el resto es muy utilizable para conocer de una forma sencilla este protocolo 🙂 Perdonad la «maquetación», he respetado el artículo tal cual fue escrito con el editor «vi» 🙂
Fijaros sobre todo en los «graficazos» que nos gastábamos en ASCII Art 😉
=[IPv6, el futuro de Internet]================================================
=[por p0th]===================================================================
| IPv6, el futuro de Internet |
0 Introduccion
1 Nomenclatura IPv6.
1.1 Nomenclatura.
2 Cabeceras IPv6
2.1 Cabecera Estandar.
2.2 Extensiones de Cabecera.
3 Deteccion de problemas y mantenimiento bajo IPv6
3.1 Mantenimiento
3.2 Neighbor Discovery.
3.2.1 Formatos para Neighbor Discovery.
3.2.2 Formato del campo de opciones del ND.
4 ICMPv6
4.1 Tipos de ICMPv6
4.2 Tipos de ICMPv6 de informacion y sus formatos
4.3 Tipos de ICMPv6 de error y sus formatos
4.4 Seguridad e ICMPv6
5 Links, bibliografia, etc...
5.1 Links.
5.2 Bibliografia.
5.3 Agradecimientos y comentarios finales.
0 Introduccion
Para todos vosotros, supongo que sera conocida la actual implementacion de
protocolo IP, es decir la version 4 del Internet Protocol, por lo que
intentare no 'abusar' de las comparativas, para no aburrir demasiado.
Tambien intentare, en lo posible, respetar los terminos adecuados,
traduciendolos entre parentesis la primera vez que sean referenciados. No
obstante, las traducciones literales de ciertos terminos, conducirian a
la confusion mas absoluta, lejos de lograr un mejor entendimiento del
concepto, por lo que conceptos como router (enrutador), enlace (link) y
socket (conector) seran directamente tratados en el idioma
anglosajon. Asi mismo, sinonimos como datagrama y paquete; pasarela,
gateway, router se usara el mas actual o mas usado, como en este ultimo
ejemplo, router. Para cualquier duda o reporte de errores en el presente
documento, enviadme un mail a la direccion que especifico en la parte
final del mismo.
|-------------------------------|
1_ Nomenclatura IPv6.
Cuando se desarrollo la actual notacion basada en direcciones de 32 Bits,
agrupados en 4 campos de 8 bits, el numero de hosts maximos que por aquel
entonces se podian direccionar resultaba muy lejano de las expectativas
que por aquel entonces se tenian de la red Internet.
Actualmente, aunque se ha visto frenada debido al uso de CIDR, el continuo
y tambien desorbitado crecimiento esta a punto de desbordar la capacidad
de IPv4. Gracias a las nuevas implementaciones de IPv6, no nos tendremos
que preocupar de este problema durante muuuuchos años.
1.1 Nomenclatura
El nuevo formato, usa una direccion de 128 bits, repartidas en
8 campos de 16 bits de la siguiente manera:
23CF:0000:0000:0000:19FC:A96C:B456:FFFF
Tambien se especifica la posibilidad de 'comprimir' campos cuyo valor sea
0, con lo que si un campo es ...:0000:... se puede usar ...:0:... en su
lugar.
Asi mismo, si algunos campos vecinos, tienen de valor 0 tambien se pueden
comprimir tal y como se explica a continuacion, basandose en la direccion
de antes:
23CF::FFFF:19FC:A96C:B456:FFFF
Donde se ha cambiado la cadena :0000:0000: por solo :: aunque no se pueden
comprimir a la vez, 2 grupos colocados en lugares no contiguos. Por
ejemplo en la direccion FFFF:0:0:0:FFFF:0:0:0, se podria
comprimir en FFFF::FFFF:0:0:0 o en FFFF:0:0:0:FFFF::, pero nunca en
FFFF::FFFF:: por que no se podria distinguir cual de los campos se usa de
relleno. Explicado en otras palabras, cuando un campo vale ::, se rellena
con 0 hasta completar la direccion.
Como es logico, las direcciones reservadas como loopback, de broadcast y
usadas en intranets, se han visto modificadas, aunque, como ya veremos,
estas ultimas no necesitaran de ser actualizadas si no es preciso.
Direcciones especiales:
IPv4 IPv6
Loopback --- 127.0.0.1 0:0:0:0:0:0:0:1 || ::1
Unspecified Adresss --- 0.0.0.0 0:0:0:0:0:0:0:0 || ::
Tambien se ha pensado en las redes que comparten las dos versiones de IP,
y se accedera a ellas del siguiente modo:
| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|0000| IPv4 address |
+--------------------------------------+----+---------------------+
Para conectarse a la maquina Host1 desde Host2, se debe especificar la
direccion IP en el formato de la V6, de la siguiente manera
0:0:0:0:0:FFFF:192.168.1.2 y Host2 es visto desde Host1 como 192.168.1.3
Si son varias redes las que hay en juego, se procede a practicar el
tunneling entre versiones por parte de los nodos.
_____________ ______________________ _______________
|Red con IPv6 | |Nodo | |Red con IPv4 |
| |==========|0:0:0:0:0:192.168.1.1 |=======| |
|Zona A | |______________________| |Zona B |
|_____________| |_______________|
_____________ ______________________ |
|Red con IPv6 | |Nodo | |
| |=========|0:0:0:0:0:192.168.2.1 |================+
|Zona C | |______________________|
|_____________|
Asi de esta forma, se pueden comunicar sin problemas, la Zona A con la
Zona C, sin necesidad de actualizar la Zona B y de una forma elegante y
transparente para los usuarios.
Para identificar a un host, perteneciente a nuestra subred, en la IPv4, se
hacia mediante la comparacion de nuestra direccion con la mascara de red.
Esto supuso una manera comoda de trabajar, aunque propicio el despilfarro
de muchisimas direcciones IP, hasta que fue frenado de manera considerable
por el uso de CIDR.
Como es logico, IPv6 realiza esta tarea de una manera mas eficiente mediante
Identificadores. El uso de estos identificadores facilitara tanto la asigna-
cion, como la identificacion de una red, independientemente de su tamaño.
En el ejemplo que se recoge en el RFC 1884, se puede observar el mecanismo
empleado para ello:
| n bits | 80-n bits | 48 bits |
+--------------------------------+-----------+--------------------+
| subscriber prefix | subnet ID | interface ID |
+--------------------------------+-----------+--------------------+
En este ejemplo, se puede observar la zona de 80 bits para el identificador de
subred y los 48 bits finales, que son asignados mediante la direccion hardware
del interfaz de red, en este caso, una tarjeta de red que cumple el estandar
IEEE-802.
Esto a su vez, permitiria una manera muy facil de asignar direcciones IP sin
mayor complicacion que la asignacion de el ID de subred comun, por lo que el
administrador, no se tendria que preocupar de asignar las direcciones ultimas
de host.
En este mismo RFC, se describen otros metodos, pero no es mi intencion
profundizar demasiado, o que este documento sea una traduccion literal del
mismo, por lo que recomiendo su atenta lectura.
|-------------------------------|
2 Cabeceras IPv6
2.1 Cabecera Estandar
Tambien, como es logico, el formato del cabecera de IP, se ha visto alterado,
y se han añadido muchas e interesantes opciones, algunas ya presentes en
IPv4, y se ha procedido a la eliminacion de las no usadas o deficientemente
implementadas.
Segun esto, una cabecera IPv6 quedaria dividida en los siguientes campos:
Version (4 bits) :
Identifica la version, y logicamente, tiene el valor 6
Traffic Class (8 bits):
Esto renueva y amplia en anterior concepto de TOS (Type of
service). Los valores de este campo, no se encuentran
estandarizados por el momento, por lo que su valor inicial,
deberia ser 00000000 por el momento.
Flow Label (20 bits):
En este campo, se pueden comunicar diferentes valores, para el
manejo del paquete para su enrrutamiento, reserva de ancho de
banda, que mejorara la recepcion de video y sonido sobre IP,
a parte de descargar al router de parte del trabajo en lo que
a administracion de calidad de servicio se refiere.
Para mas informacion sobre este valor, recomiendo la
lectura del Apendice A en el RFC 2460.
Payload Length (16 bits como unsigned integer):
Expresa la longitud de la carga del paquete en bytes (octetos)
Next Header (8 bits):
Comunica el tipo de cabecera siguiente a la de IPv6. Como por
ejemplo, 6 para TCP. Los valores son los mismos que usa IPv4
aunque en la anterior especificacion, este campo tomaba el
nombre de 'Protocol', y se recogen en el RFC 1700.
Hop Limit (8 bits como unsigned integer):
Este campo sustituye al TTL de IPv4, y tiene un valor inicial
determinado por el host emisor en un rango de 0 a 255. Cuando
un paquete llega a un router, a este valor se le resta 1 y si
este llega a 0, es descartado por el mismo.
Source Address (128 bits):
Direccion de origen del paquete.
Destination Address (128 bits):
Direccion de destino, aunque como se explica en la seccion, se
puede añadir la ruta por la cual se debe encaminar el paquete.
2.2 Extensiones de cabecera
Como novedad, se implementa el concepto extensiones de cabeceras. Estas, son
como 'añadidos' a la cabecera estandar, lo que hace mas modulables y
extensibles las posibilidades de IPv6.
Estan extensiones, se identifican mediante el campo 'Next Header'. Los nuevos
identificativos son:
Hop-by-Hop Options (Valor de next header de la cabecera anterior 0)
Routing (Valor de next header de la cabecera anterior 43)
Fragment (Valor de next header de la cabecera anterior 44)
Destination Options (Valor de next header de la cabecera anterior )
Authentication (Valor en el campo next header de la cabecera anterior 51)
Encapsulating Security Payload (Valor de next header de la cabecera anterior50)
Last header (Valor en el campo next header de la cabecera anterior 59)
Destination Options (Valor en el campo next header de la cabecera anterior 60)
En el RFC 2460, se pone como ejemplo los siguientes:
+---------------+------------------------
| IPv6 header | TCP header + data
| |
| Next Header = |
| TCP |
+---------------+------------------------
+---------------+----------------+------------------------
| IPv6 header | Routing header | TCP header + data
| | |
| Next Header = | Next Header = |
| Routing | TCP |
+---------------+----------------+------------------------
+---------------+----------------+-----------------+-----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data
| Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP |
+---------------+----------------+-----------------+-----------------
Que pueden ayudar a comprender el importate alcance de incluir esta capa
dentro de un datagrama. Cabe destacar, que una version propietaria, puede
incluir sus propias extensiones. Logicamente, se tienen que cumplir las
minimas requeridas por el RFC 2460, que son las siguientes que se comentan
brevemente a continuacion:
> Hop-by-Hop Options:
Son opciones, cuyo valor debe ser revisado por todos los nodos
por los que el paquete es encaminado.
Tiene el siguiente formato:
+--------------+----------------+------------------+
|Next header | Hdr Ext Len | Options |
+--------------+----------------+------------------+
En el campo Next Header se expecifica el tipo de cabecera inmediatamente
siguiente a esta, indicandolo mediante un selector de 8 bits.
En el campo Hdr Ext Len ( Header Extended Lenght) se especifica la longitud
del campo options, exceptuando los primeros 8 bytes. Se indica como
un valor de 8 bits unsigned integer.
En el campo Options, se incluyen las opciones que se especifican en el
apartado 4.2 del RFC 2460. Su longitud es variable aunque la suma de la
longitud de la cabecera Hop-by-Hop, debe ser multiplo de 8 bytes.
> Routing:
Esta cabecera, posibilita una de las funciones mas taractivas de la
version 6 de IP. Su funcion, es la de poder especificar el camino exacto que
preferentemente debe recorrer un paquete hasta llegar a su destino.
El formato es el siguiente:
+---------------+---------------+---------------+---------------+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+---------------+---------------+---------------+---------------+
En el campo Next Header se expecifica el tipo de cabecera inmediatamente
siguiente a esta, indicandolo mediante un selector de 8 bits.
En el campo Hdr Ext Len ( Header Extended Lenght) se especifica la longitud
de la cabecera routing, exceptuando los primeros 8 bytes. Se indica como
un valor de 8 bits unsigned integer.
El campo Routing Type es un selector de 8 bits de tamaño, que indica el tipo
de cabecera 'routing' que de momento es 0. Este tipo de cabeceras de
enrrutado, tiene el siguiente formato:
+---------------+---------------+-----------------+---------------+
| Next Header | Hdr Ext Len | Routing Type = 0| Segments Left |
+---------------+---------------+-----------------+---------------+
| (Reservado) |
+-----------------------------------------------------------------+
| Direccion 1 |
+-----------------------------------------------------------------+
| Direccion 2 |
+-----------------------------------------------------------------+
| Direccion x |
+-----------------------------------------------------------------+
En este tipo de cabecera de enrrutado, se especifican en el campo de
direcciones la IP por la que el paquete debe pasar para llegar a su destino.
Cuando un paquete llega a 'Direccion 1' esta, coloca si propia direccion en el
ultimo lugar y envia el paquete a la 'Direccion 2' que hace el mismo
procedimiento y se decrementa en 1 el campo Segments Left. Cuando se llega al
destino final. El paquete conserva la ruta completa por la que ha pasado y es
utilizada para enviar el retorno. Para obtener informacion mas extensa, asi
como un algorritmo de manejo de esta clase de cabeceras, te remito al RFC 2460.
El campo Segments Left de la cabecera de routing, se indica el
numero se segmentos de red, que quedan para que el paquete llege a su destino.
En cada salto, este numero se decrementa en 1. Su valor se comunica mediante
un unsigned integer.
> Fragment:
Al contrario de la IPv4, la fragmentacion unicamente debe ser
efectuada en el host de origen. Si el router se encontrara con un paquete de
un tamaño mayor al que puede manejar el siguiente salto, debe descartarlo y
enviar al host de origen un ICMP que comunique la MTU del siguiente salto.
El formato de esta clase de cabeceras es el siguiente:
+---------------+---------------+-------------------------+---+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+---------------+---------------+-------------------------+---+-+
| Identification |
+---------------------------------------------------------------+
En el campo Next Header se expecifica el tipo de cabecera inmediatamente
siguiente a esta, indicandolo mediante un selector de 8 bits.
El campo Reserved esta reservado para usos futuros y debe ser inicializado a
0 en el origen e ignorado en la recepcion. El valor debe ser de 8 bytes del
tipo unsigned integer.
El campo Fragment Offset es de una longitud de 13 bits, e indica
desplazamientos, en bloques de 8 bytes relativos al primer paquete de la serie.
El campo Res, esta reservado para usos futuros y debe ser inicializado en
origen a 0 e ignorado por el destino.
La flag M, inica mediante un bit, si el paquete es el ultimo (valor 0) o por
el contrario es uno mas de la serie (valor 1)
> Destination Options
Esta cabecera, indica las opciones que deben procesarse en el
destino o en los destinos en el caso de multienvios.Si va acompañada por
cabeceras de enrutamiento, la cabecera de opciones de destino colocada antes
de la de enrrutamiento, se aplica a todos los nodos, mientras que la que se
encuantra al final, es solo aplicable a la direccion de destino. Su formato es
el siguiente:
+--------------+----------------+------------------+
|Next header | Hdr Ext Len | Options |
+--------------+----------------+------------------+
En el campo Next Header se expecifica el tipo de cabecera inmediatamente
siguiente a esta, indicandolo mediante un selector de 8 bits.
En el campo Hdr Ext Len ( Header Extended Lenght) se especifica la longitud
de la cabecera Destination Options, exceptuando los primeros 8 bytes. Se indica como
un valor de 8 bits unsigned integer.
El campo options, de longitud variable, no se han especificado mas opciones
que las de relleno hasta que el tamaño sea multiplo de 8 bytes.
> Authentication:
Debida la extension de esta especificacion y el estado de desarrollo,
Ver RFC 2402
> Encapsulating Security Payload:
Debida la extension de esta especificacion y el estado de desarrollo,
Ver RFC 2406
Todas ellas, deben seguir un orden dentro del datagrama:
IPv6 header
Hop-by-Hop Options header
Destination Options header
Routing header
Fragment header
Authentication header
Encapsulating Security Payload header
Destination Options header
Upper-layer header
|-------------------------------|
3 Deteccion de problemas y mantenimiento bajo IPv6
3.1 Mantenimiento
Con la nueva version de IP, a parte de la eliminacion de mascaras de red, y
limitaciones en el numero de direcciones disponibles, los desarrolladores del
Internet Protocol han decidido facilitarle mucho la vida a los administradores.
Una red que corra sobre IPv6, sera una red facil de administrar, con menos
carga en los routers y con muchos problemas menos de trafico que la 'antigua'
IPv4.
Esto no quiere decir que una red sobre IPv6, sea el paraiso, por que el
trabajo de administrador siempre sera el de administrar, hoy estoy muy
inspirado :), y las cosas que se han de administrar, suelen tener tendencia a
desadministrarse, bonito trabalenguas.
Para el montage de una red sobre IPv6, se han desarrollado nuevos protocolos,
y se han extendido muchos de los existentes. En el RFC 2452, se da una clara
exposicion de los cambios dentro del MIB, extendiendose en el 2454 y en el
RFC 2465. Parece ser que el snmp va a pasar un periodo de nueva juventud, y un
uso mas extendido por parte de los administradores.
Soluciones mas completas como la del DHCPv6, explicada en el RFC 2462,
permiten que un host, no solo obtenga una IP con la seguridad de que es unica
en su red, si no que sea tambien dado de alta en el servidor de DNS,
solicitando un nombre directamente al servidor DHCPv6.
Tampoco el ARP se salva de la quema, y sus funciones son mucho mejor cubiertas
por nuevos procedimientos explicados en este mismo documento, en la seccion 3.2
Problemas como los traslados de equipos a otras redes y/o la reconfiguracion
de la misma para ampliarla, seran historia en la nueva version IP.
3.2 Neighbor Discovery
El Neighbor Discovery protocol (protocolo de descubrimiento de vecindad), es
el encargado de saber por que hosts/redes estamos rodeados. Esto, tambien
incluye descubrir las caracteristicas del medio por donde van a circular los
paquetes que salgan de nuestra maquina. El Neighbor Discovery hace uso de
ICMPv6, para comunicarse, tal y como se especificara en el siguiente capitulo.
Tal y como se comenta en el RFC 2461, el Neighbor Discovery, es una
combinacion de ARP, ICMP Router Discovery e ICMP redirect, y a su vez se han
incorporado nuevas funciones. Entre las funciones de este protocolo, estan
las de:
Router Discovery (Descubrimiento de router): Comunica al host y a otros
routers, la existencia de un nuevo router, o la permanencia / eliminacion de
los actuales.
Parameter Discovery (Descubrimiento de parametros): Da informacion a los nodos
de una red, sobre el MTU, asi como del numero maximo de saltos para llegar al
exterior.
Prefix Discovery (Descubrimiento de prefijo): Comunica al nodo el prefijo de
la red, que tiene la direccion IPv6 de su subred.
Next-hop determination (Determinacion del proximo salto): Comunica el nodo
mas cercano. Este valor puede ser usado para determinar la ruta mas corta por
la cual se encaminaran los paquetes.
Address Autoconfiguration (Autoconfiguracion de direccion): Da a conocer a
la maquina, la IP de un interfaz de red.
Address resolution (Resolucion de direccion): Haciendo un poco de humor, se
le puede llamar 'El artista antes conocido como ARP' ;). Se encarga de
establecer la corespondencia entre la direccion IP y la de su capa de enlace
(Direccion MAC de una ethernet por ejemplo).
Neighbor Unreachability Detection (Deteccion de inalcanzabilidad de un
vecino): Detecta la caida, o eliminacion de un router y/o host.
Duplicate Address Detection (Deteccion de Duplicidad de direcciones):
Comprueba que no hay direcciones IP duplicadas dentro de una red. Puede ser
usado antes de dar de alta un nuevo nodo.
Redirect (Redireccion): Informa a un nodo, de el mejor camino mas corto, para
alcanzar un destino.
3.2.1 Formatos para Neighbor Discovery.
Los formatos para los mensages, quedan definidos de la siguiente manera.
Router Solicitation:
+---------------+---------------+-------------------------------+
| Type | Code | Checksum |
+---------------+---------------+-------------------------------+
| Reserved |
+---------------------------------------------------------------+
| Options ... |
+---------------------------------------------------------------+
Los valores para estos campos, son los siguientes:
Type: 133
Code: 0
Checksum: (Suma de control ICMPv6)
Reserved: 0 (Sin un valor asignado)
Options:
- Source link-layer address
Direccion de la capa de enlace del origen del mensage.
Router Advertisement:
+---------------+---------------+-------------------------------+
| Type | Code | Checksum |
+---------------+---------------+-------------------------------+
| Cur Hop Limit |M|O| Reserved | Router Lifetime |
+---------------+-+-+-----------+-------------------------------+
| Reachable Time |
+---------------------------------------------------------------+
| Retrans Timer |
+---------------------------------------------------------------+
| Options ... |
+---------------------------------------------------------------+
Los valores para estos campos, son los siguientes:
Type: 134
Code: 0
Checksum: (Suma de control ICMPv6)
Cur Hop Limit: Valor actual que debe tomar el campo de IP que indica el
numero de saltos por defecto, o Hop Limit, especificado en 8 bytes unsigned
integer. Un valor de 0, no especifica nada.
M: Flag de 1 bit, para el Managed address configuration.
O: Flag de 1 bit, para el Other stateful configuration.
Reserved: Campo reservado para usos futuros. Con valor de 6 bit, debe ser
inicializado a 0. Cualquier otro valor, sera ignorado.
Router Lifetime: Valor de 16 bits unsigned integer. El tiempo de vida del
router por defecto. Si el valor es 0, no debe ser usado para este fin.
Reachable Time: Tiempo medido en 32 bits unsigned integer, que indica, en
milisegundos, el tiempo desde que un nodo, ha recibido una confirmacion de
alcance, por parte de sus vecinos. Un valor de 0, no especifica nada.
Retrans Timer: Tiempo en milisegundos, expresados como unsigned integer,
trascurrido entre 2 mensajes de solucitud de vecindad. Un valor de 0,
inhabilita este campo.
Options:
- Source link-layer address
Direccion de la capa de enlace del origen del mensage.
-MTU
Debe ser enviada en redes con la MTU variable. En otra clase de enlaces,
esta opcion es opcional.
-Prefix Information
Los prefijos de las redes que alcanza el router excepto la local.
Neighbor Solicitation
+---------------------------------------------------------------+
| Type | Code | Checksum |
+---------------------------------------------------------------+
| Reserved |
+---------------------------------------------------------------+
| Target Address |
+---------------------------------------------------------------+
| Options ... |
+---------------------------------------------------------------+
Los valores para estos campos, son los siguientes:
Type: 135
Code: 0
Checksum: (Suma de control ICMPv6)
Reserved: 0 (Sin un valor asignado)
Target address: Direccion IP hacia la cual se envia la solucitud. Este campo
no debe ser ocupado por una direccion de multicast.
Options:
- Source link-layer address
Direccion de la capa de enlace del origen del mensage.
No debe incluirse si es una direccion de arranque. En cambio si ya tiene IP,
puede ser incluida si es una solicitud de multicast y debe ser incluida si es
una solicitud de anycast.
Neighbor Advertisement
+---------------------------------------------------------------+
| Type | Code | Checksum |
+---------------------------------------------------------------+
|R|S|O| Reserved |
+---------------------------------------------------------------+
| Target Address |
+---------------------------------------------------------------+
| Options ... |
+---------------------------------------------------------------+
Los valores para estos campos, son los siguientes:
Type: 136
Code: 0
Checksum: (Suma de control ICMPv6)
R: Router flag de un bit. Indica que el nodo de envio es un router. Es usado
por el Neighbor Unreachability Detection, para ver si un router cambia a host.
S: Solicited flag de un bit. Toma valor 1, si el mensage es en respuesta a
una solicitud de vecindad.
O: Override flag. Con valor 1, indica que la cache de destino debe ser
actualizada. Si el valor es 0, la cache de destino no debe ser actualizada
menos para los nodos implicados.
Reserved: 29 bits sin uso, destinados a furusar implementaciones. debe ser
inicializado a 0. Otro valor, sera ignorado.
Target Address: Direccion de destino, que debe ser la del nodo que solocito
este mensage. No debe ser ninguna direccion de multicast.
Options:
- Target link-layer address
Direccion de la capa de enlace del destino. Puede ser incluida respondiendo a
una solicitud de multicast y debe ser incluida si es una respuesta a
una solicitud de anycast.
Redirect
+---------------------------------------------------------------+
| Type | Code | Checksum |
+---------------------------------------------------------------+
| Reserved |
+---------------------------------------------------------------+
| Target Address |
+---------------------------------------------------------------+
| Destination Address |
+---------------------------------------------------------------+
| Options ... |
+---------------------------------------------------------------+
Los valores para estos campos, son los siguientes:
Type: 137
Code: 0
Checksum: (Suma de control ICMPv6)
Reserved: 0 (Sin un valor asignado)
Target Address: Informa al host, de que hay un camino mejor por donde
encaminar su trafico hacia su destino, indicandolo en este campo.
Destination Address: Aqui informa el router al host, el destino del trafico
al cual se refiere.
Options:
-Target link-layer address
Direccion de la capa de enlace del destino. Debe incluirse si es posible. En
enlaces del tipo NBMA (non-broadcast multi-access), los host podria requerir
la direccion de la capa de enlace del destino.
-Redirected Header
Incluir tanto como sea posible de la cabecera IP del paquete que ha probocado
el envio del mensage.
3.2.2 Formato del campo de opciones del ND.
Dentro de los mensages anteriormente citados, el campo Options debe tener este
formato:
-Source/Target Link-layer Address
+---------------+---------------+---------------------------+
| Type | Length | Link-Layer Address ... |
+---------------+---------------+---------------------------+
Type:
1 Para el Source Link-layer Address
2 Para el Target Link-layer Address
Length: Longitud, incluyendo el campo Type y Length medida en valores de 8
bytes.
Link-Layer Address:
Direccion de la capa de enlace. Su formato esta a la espera de ser
especificado.
-Prefix Information
+---------------+---------------+---------------+-+-+-----------+
| Type | Length | Prefix Length |L|A| Reserved1 |
+---------------+---------------+---------------+-+-+-----------+
| Valid Lifetime |
+---------------------------------------------------------------+
| Preferred Lifetime |
+---------------------------------------------------------------+
| Reserved2 |
+---------------------------------------------------------------+
+ Prefix +
| |
+---------------------------------------------------------------+
Type: 3
Length: 4
Prefix Length: 8 bits de unsigned integer en un rango de 0 a 128 que indican
las primeras posiciones del prefijo que son validas.
L: Flag de on-link. Con valor 1, indica que la direccion es del tipo on-link,
a 0, no especifica nada.
A: Flag de autonomous address-configuration (configuracion autonoma de
configuracion). Con valor 1, indica que el prefijo puede ser usado para que el
host configure su direccion.
Reserved1: Campo de 6 bits reservados para uso futuro. Se debe inicializar a 0.
Valid Lifetime: Valor de 32 bits insigned integer, que informa del tiempo en
segundos que el prefijo, a fines de direcciones on-link, debe ser valido. Si
el campo son todos 1 (0xffffffff) el valor es infinito.
Preferred Lifetime: Valor de 32 bits insigned integer, que indica el tiempo en
segundos, que la direccion generada a partir del prefijo es preferible que sea
usada. Si el campo son todos 1 (0xffffffff) el valor es infinito.
Reserved2: Campo reservado para uso futuro. Se debe inicializar a 0.
Prefix: Contiene una direccion IP o un prefijo IP. El campo Prefix Length
contiene los bits primeros a tener en cuenta y el resto deben ser
inicializados a 0 e ingnorados por el que envia el mensage. Un router no debe
mandar prefijos hacia links locales y un host local, debe ignorarlo.
-Redirected Header
+---------------+---------------+-------------------------------+
| Type | Length | Reserved |
+---------------+---------------+-------------------------------+
| Reserved |
+---------------+---------------+-------------------------------+
| |
~ IP header + data ~
| |
+---------------------------------------------------------------+
Type: 4
Length: longitud en unidades de 8 bytes de la opcion.
Reserved: Campo reservado para futuros usos. Debe ser inicializado a 0.
IP header + data: Paquete original truncando su tamaño para que, la longitud
total, no exceda de 1280 bits.
-MTU
+-------------+---------------+-------------------------------+
| Type | Length | Reserved |
+-------------+---------------+-------------------------------+
| MTU |
+-------------+---------------+-------------------------------+
Type: 5
Length: 1
Reserved: Campo reservado para futuros usos. Debe ser inicializado a 0.
MTU: 32 bits unsigned integer que indica el MTU recomendado. El valor debe ser
aplicado a todos los segmentos.
Si algun campo de opciones es encontrado dentro de un tipo de mensage que no
le corresponde, debe ser simplemente ignorado por el router.
El Neighbor Discovery, es un protocolo tan extenso, que ocupa un RFC entero
(el RFC 2461). Solo he querido tratarlo muy por encima, por lo que sugiero su
lectura para mayor informacion.
|-------------------------------|
4 ICMPv6
El Internet Control Messages Protocol (56 en el campo de Next Header), tiene
el mismo uso que su antepasado, el ICMPv4. La mision de un ICMP, es sobre todo
la de informar. Sobre que informa, como y de que forma, lo tratare de explicar
en las siguientes secciones.
4.1 Tipos de ICMPv6 y formato
Los mensages de ICMP, se han dividido en 2 clases, los que comunican errores,
y los que piden/dan informacion sobre un nodo. Para diferenciarlos, se han
adjudicado una numeracion del 0 al 127 a los mensages que contienen
informacion y del 128 al 255, sobre los que informan de algun tipo de error de
una peticion.
Un paquete ICMPv6, esta formado por una cabecera IPv6, y es precedido
inmediatamente por una cabecera con valor 58 en el campo next header:
+---------------+------------------------
| IPv6 header | ICMP header + data
| |
| Next Header = |
| 58 |
+---------------+------------------------
Notese, que este procedimiento es diferente al de IPv4, y que un ICMP puede
ser insertado en cualquier tipo de paquetes.
4.2 Tipos de ICMPv6 de informacion
Los mensages de informacion, pueden ser del tipo:
Echo Request (Type 128)
Un nodo, puede enviar un ICMP Echo Request (Mas conocidos como pings), para
saber el tiempo de respuesta de otro host.
El formato es el siguiente:
+---------------+---------------+-------------------------------+
| Type | Code | Checksum |
+---------------+---------------+-------------------------------+
| Identifier | Sequence Number |
+-------------------------------+-------------------------------+
| Data ... |
+---------------------------------------------------------------+
Type: 128
Code: 0
Checksum: Suma de control, para la comprobacion de la informacion.
Identifier: Identificador para contrastar los ICMP Echo Reply de respuesta.
Sequence Number: Secuencia de numeros, para contrastar los ICMP Echo Reply
de respuesta en orden.
Data: Datos aleatorios o ceros de relleno.
La recepcion de ICMP Echo Request, debe ser comunicada a la capa superior de
trasporte.
Echo Reply (Type 129)
El ICMP Echo Reply, es enviado como respuesta a un ICMP Echo Request. El ICMP
Echo Reply debe ser trasportado al proceso que origino el ICMP Echo Request.
Su formato es el siguiente:
+---------------+---------------+-------------------------------+
| Type | Code | Checksum |
+---------------+---------------+-------------------------------+
| Identifier | Sequence Number |
+-------------------------------+-------------------------------+
| Data ... |
+---------------------------------------------------------------+
Type: 129
Code: 0
Checksum: Suma de control, para la comprobacion de la informacion.
Identifier: Identificador que debe contrastar con los ICMP Echo request
que se han recibido.
Sequence Number: Secuencia de numeros, que debe contrastar con los ICMP Echo
request que se han recibido en el mismo orden.
Data: Datos aleatorios o ceros de relleno.
4.3 Tipos de ICMPv6 de error
Destination Unreachable (Type 1)
Un ICMP Destination Unreachable es mandado por un router, o por cualquier
nodo, para informar de la imposibilidad de que un paquete lleje a su destino.
NO se deberian mandar ICMPv6, si son ocasionados por problemas de congestion
de la red.
Estos ICMP se dividen en subclases, segun el tipo de problema que halla
ocasionado su emision:
-Si el error es ocasionado por un envio de un paquete al nodo erroneo, este
enviara un ICMPv6 con codigo 0
-Si el error es ocasionado por un envio hacia un destino cerrado por causas
administrativas (Un firewall por ejemplo), se debe enviar un ICMP de codigo 1.
-Si el error es ocasionado por la imposibilidad de resolver la direccion IP de
un link, se enviara un ICMPv6 con codigo 3.
-Si el error es ocasionado por un fallo en la capa de trasporte si el
puerto esta indisponible para la misma se enviara un ICMP con codigo 4. Por
ejemplo, un paquete TCP enviado a un puerto UDP.
Un nodo que ha recibido un ICMPv6 Destination Unreachable, debe comunicarlo a
la capa superior del proceso.
El formato seria el siguiente:
+---------------+---------------+-------------------------------+
| Type | Code | Checksum |
+---------------+---------------+-------------------------------+
| Unused |
+---------------------------------------------------------------+
| La maxima cantidad posible de datos del |
| paquete originario del error, sin exceder |
| el tamaño del MTU. |
+---------------------------------------------------------------+
Type: 0
Code: 0 - no route to destination
1 - communication with destination administratively prohibited
2 - (not assigned)
3 - address unreachable
4 - port unreachable
Unused: Campo sin uso, que debe ser inicializado a 0 por el emisor e ignorado
por el destino.
Checksum: Suma de control, para la comprobacion de la informacion.
Packet Too Big (Type 2)
Un ICMP Packet Too Big , es enviado cuando el tamaño maximo de un paquete es
superior a la MTU del interfaz de red al que se ha enviado. Tambien es enviado
por un router, si el siguiente salto es tiene un MTU inferior al tamaño del
paquete. Este ICMP, puede ser usado para saber el MTU de un path.
El formato seria el siguiente:
+---------------+---------------+-------------------------------+
| Type | Code | Checksum |
+---------------+---------------+-------------------------------+
| MTU |
+---------------------------------------------------------------+
| La maxima cantidad posible de datos del |
| paquete originario del error, sin exceder |
| el tamaño del MTU. |
+---------------------------------------------------------------+
Type: 2
Code: 0 (Inicializado a 0 por el origen, ignorado por el destino)
Checksum: Suma de control, para la comprobacion de la informacion.
MTU: MTU del siguiente salto.
Time Exceeded (Type 3)
Si un router recive un paquete con el Hop limit a 0 o si es el quien
lo tiene que poner a 0, el paquete es descartado y se envia un ICMPv6 Time
Exceeded. Si un host, no puede ensamblar un paquete en un tiempo x, descartara
todos los fragmentos recibidos y tambien enviara un ICMP de esta clase.
La llegada de un ICMPv6, debe ser notificada a la capa superior de trasporte.
El formato queda de esta forma:
+---------------+---------------+-------------------------------+
| Type | Code | Checksum |
+---------------+---------------+-------------------------------+
| Unused |
+---------------------------------------------------------------+
| La maxima cantidad posible de datos del |
| paquete originario del error, sin exceder |
| el tamaño del MTU. |
+---------------------------------------------------------------+
Type: 3
Code: 0 - hop limit exceeded in transit (Rebasado el limite de saltos)
1 - fragment reassembly time exceeded (Rebasado el tiempo de
ensamblado en destino)
Unused: Campo inicializado a 0 en origen, e ignorado por destino.
Checksum: Suma de control, para la comprobacion de la informacion.
Parameter Problem (Type 4)
Si un nodo IPv6, al procesar un paquete, encuantra un error en uno de los
parametros de sus campos, enviara un ICMP Parameter Problem informando al
destino de la situacion del error en el paquete.
El formato quedaria asi:
+---------------+---------------+-------------------------------+
| Type | Code | Checksum |
+---------------+---------------+-------------------------------+
| Pointer |
+---------------------------------------------------------------+
| La maxima cantidad posible de datos del |
| paquete originario del error, sin exceder |
| el tamaño del MTU. |
+---------------------------------------------------------------+
Type: 4
Code: 0 - erroneous header field encountered (Error en la cabecera)
1 - unrecognized Next Header type encountered (Numero de Next Header
desconocido)
2 - unrecognized IPv6 option encountered (Opcion desconocida en el
paquete IPv6)
Checksum: Suma de control, para la comprobacion de la informacion.
Pointer: Contiene un offset, para la localizacion del parametro que origino el
error. El offset, es el byte donde se encuentra el dato erroneo
dentro del paquete.
4.4 Seguridad e ICMPv6
Los ataques producidos por los ICMP enviados de forma masiva, generalmente para
provocar un DOS (Denial of Service) y/o la caida de un nodo de una red y/o de
una conexion, son lo suficientemente conocidos como para no tener que volver a
explicarlos.
El protocolo IPv6, implementa medios de autentificacion que pueden evitar los
mas comunes.
-Caida por recepcion de envios masivos de ICMP.
-Desconexion de un host, por el envio de un atacante al servidor, de ICMP con
mensages de error.
-Falsificacion de ICMP.
Todos estos problemas, estan descritos en el RFC 2463, asi como sus posibles
soluciones mediante aplicaciones de metodos autentificadores a niver de
trasporte IP y/o mediante el chesum de control.
|-------------------------------|
5 Links, bibliografia, etc...
5.1 Links sobre IPv6
*+* Url donde se centraliza IPv6
http://www.ipv6.org
http://dir.yahoo.com/Computers_and_Internet/Comunications_and_Networking/
Protocols/IP/IPv6
ftp://ftp.inria.fr/network/ipv6/netbsd
ftp://ftp.inria.fr/network/ipv6/freebsd
http://www.ipv6.nrl.navy.mil/ipv6+ipsec/
http://sunsite.cnlab-switch.ch/
http://www.redhat.com/mirrors/LPD/HOWTO/Net-HOWTO-6.html
http://www.terra.net/ipv6/
http://playground.sun.com/pub/ipng/html/ipng-main.html
ftp://ftp.kyoto.wide.ad.jp/IPv6/
http://www.research.microsoft.com/msripv6 (tnx zhodiac)
ftp://ftp.kame.net./pub/kame/misc/
5.2 Bibliografia.
TCP/IP *** Dr. Sidnie Feit
TCP/IP Illustrated Vol 1 *** W. Richard Stevens (D.E.P)
Computers Networks *** Andrews S. Tannembaum
HOW-TO de Linux
RFC:
2373 IP Version 6 Addressing Architecture
2462 IPv6 Stateless Address autoconfiguration
2461 Neighbor Discovery for IP Version 6
2460 Internet Protocol, Version 6 (IPv6) Specification
2463 Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification
2454 IP Version 6 Management Information Base for the
User Datagram Protocol
2553 Basic Socket Interface Extensions for IPv6
2543 6Bone Routing Practice
2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
5.3 Agradecimientos y comentarios finales.
En primer lugar a todos los de Undersec.com, mis amigos; a ABBA, la banda
sonora de este doc ;), a todos los que me devolvieron la ilusion por lo que
hacia, cuando se acercaba el precipicio y Linux, mi vicio actual (Por lo
menos el mas confesable ;).
Como comentario final, recomendaria que se leyera este doc como un apoyo
solamente. Para una informacion mas profunda, se deben leer los rfc destinados
a tal fin, y comentados en la seccion de bibliografia.
Espero que hayas disfrutado leyendo.
-------------------------------------------------------------------------------
Septiembre de 1999
http://www.undersec.com
p0th@undersec.com
Mucho articulo no lo entiendo pero ahora doy ipv6 en clase y me va a venir bien. ¿Como me paso a ipv6?