Captulo 2

Captulo2:ProtocolodeInternet
En este captulo se presenta una introduccin acerca del protocolo de Internet y las caractersticas
esenciales de la versin 4 de este protocolo; as como, la estructura de su encabezado de red. Debido a
la evolucin de este protocolo en su encabezado de red, la siguiente versin propuesta
(correspondiente al nmero 6) es descrita en este captulo de manera ms detallada. Se realiza una
introduccin al protocolo de Internet versin 6 comparando las diferencias que existen entre este
encabezado y el de IPv4. As mismo, se hace una descripcin de la nueva notacin de direcciones IP
utilizadas por esta versin y de la introduccin de los prefijos como parte de stas.

2.1Introduccin
Actualmente las redes de telecomunicaciones crecen cada vez ms rpido conforme ms servicios de
red convergen entre s, como: telefona, multimedia y transmisin de datos. Como era de esperarse,
estos servicios integrados incluyen en s mismos redes inalmbricas, redes mviles, como las clsicas
redes almbricas. De esta manera, una consecuencia a este rpido desarrollo es la dificultad para
comprender la interaccin entre los protocolos, cada vez ms complejos, de estos servicios [FEY01].
En general es bien sabido que el Internet como lo conocemos enfrentar un serio problema
dentro algunos aos ya que su rpido crecimiento y sus limitaciones en cuanto a diseo, llegar al punto
en el que no habr ms direcciones disponibles para agregar nuevos usuarios a la red. Al llegar a esta
situacin se augura que no se podrn instalar nuevos servidores de red ni ms usuarios podrn
suscribirse a algn Proveedor de Servicios de Internet (Internet Service Provider, ISP) [RAM05].
A principios de los aos 90, se hizo notar que el reducido espacio de direcciones IPv4 junto con
la falta de coordinacin para su asignacin durante la dcada de los 80, sin ningn tipo de optimizacin
dejando incluso espacios de direcciones discontinuos, generara dificultades no previstas en aquel

Captulo 2

momento [RAM05]. La mayora de las predicciones acerca de cundo se agotaran por completo las
direcciones IPv4 estaban erradas. La principal razn de esto se debi a que el enfoque fue realizado con
respecto a la densidad de las direcciones y no en su proceso de distribucin con el paso de los aos
[FEY01]. Se puede observar que del total de espacio destinado para IP, un 6% se encuentra reservado,
otro 6% es utilizado para realizar multicast, el 51% del espacio ha sido asignado a algn dispositivo, y el
37% restante (cerca de 1.5 billones de direcciones) no ha sido an asignado [HUS03]. Aunque an
quedan cerca del 30-37% de direcciones disponibles, las cuales pueden ser utilizadas para asignar
unicasts globales de direcciones IP a Registros Regionales de Internet (Regional Internet Registries, RIR)
[KOT05], en realidad es difcil obtener bloques de direcciones IP debido a las estrictas polticas
impuestas por los RIRs [VAR02]. Una actualizacin a este protocolo era inminente y el motivo bsico
para la creacin del nuevo protocolo era la futura falta de direcciones.
Algunas aproximaciones se han realizado para resolver este problema de falta de
direccionamiento. Una opcin muy popular es la de no asignar a cada mquina una direccin IP nica y
utilizar , en vez de esto, un grupo de direcciones locales privadas y despus traducirlas a direcciones
pblicas. En la mayora de los casos puede ser slo una direccin la que se asigne y que soporte la
comunicacin entre diversos puntos locales privados y puntos pblicos externos [HUS03]. Esta opcin
es conocida como NAT (Network Address Translation) [FEY01]; sin embargo, esta aproximacin presenta
problemas al no permitir a sus computadoras protegidas poder ser accesadas en conexiones abiertas o
del tipo peer-to-peer (P2P) [FEY01].
Otras aproximaciones llevas a la prctica comn son el caso de DHCP (Dynamic Host
Configuration Protocol), que se encargada de asignar direcciones IP a dispositivos de red de una manera
dinmica sin desperdiciar direcciones en direcciones inactivas de un nodo desconectado de la red. O el
caso de VLSM (Variable Length Subnet Mask) es otro mecanismo que provee direcciones IPv4 con
mscaras de longitud variable utilizando el mismo bloque de direcciones; es decir, el direccionamiento
se hace en base a la necesidad individual de la red. Otra de las aproximaciones ms populares llevadas a
la prctica es el subnetting; ste, es un proceso que nos permite dividir un espacio de direcciones en
subredes y dar lugar a un aprovechamiento ptimo de las direcciones [RFC 950].

10

Captulo 2

2.2ProtocolodeInternetversin4(IPv4)
Mencionado anteriormente, el protocolo de Internet (IP) es un protocolo que pertenece a la Capa de
red segn el modelo TCP/IP que es utilizado por los protocolos de capa de transporte, como TCP,
para encaminar los datos hacia su destino. IP tiene nicamente la misin de direccionar los datagramas
generado en capa de red, sin comprobar la integridad del contenido.
Anteriormente no se sola hacer la distincin entre versiones del protocolo IP; pero, con la
llegada de la versin 6 de ste se tuvo que empezar a diferenciar IPv6 de se su versin anterior, la
versin 4. Una direccin IP versin 4 tiene una longitud de 32 bits escritos de la forma dotted quad,
a.b.c.d, en donde cada una de a, b, c y d, representan un nmero decimal dentro del rango de 0 a 255.
Dado esto, el rango de direcciones va desde 0.0.0.0 hasta 255.255.255.255, lo que significa que shay
un lmite en cuanto al nmero de direcciones IP que se puede proporcionar. IPv4 ofrece una
posibilidad de 232 nmero de direcciones, esto es 4, 294, 967, 296 o 4 billones de direcciones.
El espacio original de direcciones fue dividido en partes fijas, a las cuales se les dio el nombre de
clases: A, B y C que son las divisiones ms conocidas de este rango. Tambin existen direcciones del
tipo D y E, pero stas estn reservadas para propsitos experimentales y de multicast [MAL05]. Una
direccin simple clase A tiene 8 bits asignados para identificar la red y 24 bits de direcciones para
identificar a los usuarios. Una clase B presenta 16 bits de identificacin de red y 16 bits para asignar las
direcciones de usuario. Por ltimo, una direccin clase C tiene 24 bits de red [MAL05] (ver Figura
2.1).
Clase/Bits
0
1
8
16
24
31
Clase A
0
Red
Nmero de usuario
Clase B
10
Nmero de Red
Nmero de usuario
Clase C
110
Nmero de Red
Nmero de Usuario
Clase D
1110
Direccin de Multicast
Clase E
1111
Reservado
Figura 2.1: Clases de direcciones IP. La primera columna identifica el tipo de Clase, la siguiente identifica
el nmero de bits que la representan.

11

Captulo 2

Se puede saber en que clase de direccin se encuentra un IP determinado, dependiendo del

rango en el que sta caiga [GOR98] (ver Tabla 2.1).
Tabla 2.1: Rangos de direccionamiento segn tipo de clase.
Clase

Rango de
direccionamiento

Porcentaje del total de

direcciones disponibles en IPv4

0.0.0.0127.255.255.255

50%

128.0.0.0191.255.255.255

25%

192.0.0.0223.255.255.255

12.5%

224.0.0.0239.255.255.255

6.25%

240.0.0.0255.255.255.255

6%

2.2.1Encabezadodetrama
El protocolo de IP es un protocolo de Capa 3 en el modelo TCP/IP y su misin es direccionar el
datagrama, generado en capa de red. Para ello se utiliza un encabezado que se antepone al datagrama
que se maneja y es el que proporciona las caractersticas de ruteo y transmisin.
Si suponemos que en la capa inmediata superior, TCP, tambin se agreg un encabezado, el
datagrama queda de la siguiente manera:

Encabezado IP
(20 bytes)

Encabezado TCP
(20 bytes)

Datos

Figura 2.2: Estructura de un datagrama.

El encabezado IP de la capa de red tiene una longitud de 160 bits que es lo mismo que 20 bytes
y est conformado por varios campos de distinto significado [GOR98] (ver Figura 2.3).

12

Captulo 2

Versin
(4 bits)

TTL

IHL (4 bits)

Tipo de servicio

Identificacin

(16 bits)

(8 bits)

Longitud total

(8 bits)

Banderas
(3 bits)

Protocolo

Fragmentacin
Comprobacin

(8 bits)

Direccin fuente

(32 bits)

Direccin destino

(32 bits)

(16 bits)

(13 bits)

(16bits)

Figura 2.3: Encabezado IPv4.

Estos campos se definen a continuacin:

1.

Versin: nmero de versin del protocolo IP utilizado. Para IPv4 este tendr un valor 4 (4 bits).

2.

Longitud de encabezado (Internet Header Length, IHL): Especifica la longitud del encabezado
expresado en el nmero de grupos de 32 bits que contiene (4 bits).

3.

Tipo de servicio (Type Of Service, TOS): se utiliza para indicar la prioridad o importancia de los
datos envados, lo que condicionar la forma en que stos sern tratados durante la transmisin. (8
bits).

4.

Longitud total: Es la longitud en bytes del datagrama completo, incluyendo el encabezado y los
datos. Como este campo utiliza 16 bits, el tamao mximo del datagrama no podr superar los
65.535 bytes, aunque en la prctica este valor es mucho ms pequeo (16 bits).

5.

Identificacin: se utiliza para facilitar el ensamble de los fragmentos del datagrama (16 bits).

6.

Banderas: Indicadores utilizados en la fragmentacin (3 bits).

7.

Fragmentacin: Contiene un valor (offset) para poder ensamblar los datagramas que se hayan
fragmentado. Est expresado en grupos de 8 bytes (64 bits), comenzando con el valor cero para el
primer fragmento (16 bits).

8.

Lmite de existencia (Time To Live, TTL): Contiene un nmero que disminuye cada vez que el
paquete pasa por un nodo. Si este nmero llega a cero, el paquete ser descartado. Esto es necesario
por razones de seguridad para evitar redundancia cclica, aunque es bastante improbable que esto
suceda en una red correctamente diseada, no debe descuidarse esta posibilidad (8 bits).

13

Captulo 2
9.

Protocolo: El nmero utilizado sirve para indicar a qu protocolo pertenece el datagrama que se
encuentra a continuacin del encabezado IP, de manera que pueda ser tratado correctamente
cuando llegue a su destino (8 bits).

10.

Comprobacin: necesario para verificar que los datos contenidos en el encabezado de IP son
correctos. Por razones de eficiencia este campo no puede utilizarse para comprobar los datos
incluidos a continuacin, sino que estos datos de usuario se comprobarn posteriormente a partir
del campo de comprobacin del encabezado siguiente, y que corresponde al nivel de capa de
transporte. Este campo debe calcularse de nuevo cuando cambia alguna opcin de encabezado,
como puede ser el lmite de existencia (16 bits).

11.

Direccin fuente: Contiene la direccin del usuario que enva el paquete (32 bits).

12.

Direccin destino: Esta direccin es la del usuario que recibir la informacin. Los ruteadores o
gateways intermedios deben conocerla para dirigir correctamente el paquete (32 bits).

2.3ProtocolodeInternetversin5
Muchas personas se preguntan que sucedi con IPv5. Porqu el cambio de IPv4 a IPv6 sin tomar la
versin 5 como opcin. En realidad IPv5 nunca existi como una versin del Protocolo de Internet; de
hecho, esta versin 5 en el encabezado identificaba paquetes que llevaban un protocolo experimental no
IP de tiempo real llamado ST (Stream Protocol).
En la dcada de 1970s, el protocolo llamado ST fue creado con propsito experimental, para
transmitir voz y video. Dos dcadas despus este protocolo fue sometido a revisin y se convirti en
ST2 y se empez a implementar en proyectos comerciales por grupos como IBM, NeXT, Apple y Sun.
Este nuevo protocolo garantizaba QoS (Quality of Service), o Calidad de Servicio, a diferencia de su
contraparte IPv4. ST y ST2 fueron asignados con la versin 5 del protocolo. Debido a que ST nunca fue
extensamente utilizado, y la versin 5 ya estaba asignada, la nueva versin del protocolo IP tuvo que
quedarse con el identificador siguiente, el 6 [RFC 1819].
Muchos fueron los intentos realizados por cambiar la manera en que las direcciones IPv4 eran
utilizadas sin tener que cambiar las bases de su encabezado. Estos mtodos slo extendan la vida de

14

Captulo 2

IPv4, mas no resolvan la obviedad del problema. Para mantener el xito de IP en un futuro era
necesario incluir planes con funcionalidades ms avanzadas y en 1994 el IPng (Internet Protocol next
generation) fue concebido en con el objetivo de empezar a migrar de protocolo pero esto nunca pas.
Cuando se asign la versin 6 al protocolo de Internet, se supona que fuera la autoridad, en
cuanto a envo de informacin se refera, sobre IPv4. Este, incrementaba el nmero de bytes utilizados
para direccionamiento (de 4 bytes a 16 bytes), introdujo el ruteo de tipo anycast, retir completamente
los encabezados de checksum de la capa de red e introdujo otra cuantas mejoras. Este campo de 8 bits
identifica si la versin utilizada es 4, en el caso que as lo sea, 5 si refiere a una versin de siguiente
generacin.

2.4ProtocolodeInternetversin6
Diseado por Steve Deering de Xerox PARC y Craig Mudge, IPv6 est destinado a sustituir al estndar
IPv4, cuyo lmite en el nmero de direcciones de red admisibles est empezando a restringir el
crecimiento de Internet y su uso, especialmente en China, India, y otros pases asiticos densamente
poblados. Este nuevo estndar pretende mejorar el servicio global; por ejemplo, proporcionando a
futuras redes telefnicas y dispositivos mviles tener direcciones propias y permanentes.
IPv4 soporta 4.294.967.296 (232) direcciones de red diferentes; mientras que, IPv6 soporta
40.282.366.920.938.463.463.374.607.431.768.211.456 (2128) 340 sextillones de direcciones
cerca de 4,3 1020 (430 trillones) direcciones por cada pulgada cuadrada (6,7 1017 670 mil
billones direcciones/mm2) de la superficie de La Tierra [RAM05]. El nuevo sistema de
direccionamiento es uno de los cambios ms importantes que aporta la versin 6 del protocolo IP,
donde se ha pasado de los 32 a los 128 bits (un nmero cuatro veces mayor) y que estas nuevas
direcciones identifican a un interfaz o conjunto de interfaces ms que a un nodo (aunque como cada
interfaz pertenece a un nodo, es posible referirse a stos a travs de su interfaz [GOR98]). El esfuerzo
que se realiza para la especificacin de IPv6 es una iniciativa recin empezada.
El trabajo realizado por la IAB (Internet Activities Board) en 1991, identific que las dos
situaciones para escalar el Internet son: un incremento en la tasa de consumo de espacio de direcciones
y un crecimiento semejante en las tablas de ruteo de interdominio. La conclusin a la que se lleg fue

15

Captulo 2

que si se asume que la arquitectura de Internet continuar en uso indefinidamente, entonces se

necesitar flexibilidad adicional (direcciones) [IAB00]. Estas iniciativas fueron retomadas mas tarde por
la IETF (Internet Engineering Task Force) con el establecimiento de ROAD (ROuting and ADressing). Este
esfuerzo pretenda examinar los temas asociados con el direccionamiento y ruteo de direcciones IP
analizando la tasa de consumo de direcciones y la tasa de crecimiento en tablas de ruteo, sin pretender
dar solucin a ellos. Pero, dado el consumo exponencial de direcciones en juego, la perspectiva sobre
el agotamiento de espacio en IPv4 era una realidad.
El mayor resultado del esfuerzo de la IETF ROAD fue la recomendacin para desaprobar los
lmites entre red-usuario asociados con las clases A, B y C de direcciones. En su lugar la IETF propuso
la adopcin de una arquitectura de direcciones y ruteo en donde estos lmites, entre el usuario y la red,
se configuraran explcitamente para cada red y que se pudieran alterar cada vez que dos o ms bloques
de direcciones se agregaban. Esta aproximacin fue conocida como CIDR (Classless Inter Domain Routing)
y tena como objetivo ganar un poco de tiempo ante el consumo exponencial de direcciones, ms no
se pretenda del todo que fuera una arquitectura escalable. Sin embargo, la arquitectura de direcciones
y ruteo IPv4 de CIDR result ser un gran xito, y 10 aos despus segua mantenindose en pie.
Se argumenta que CIDR es importante, ms no la nica razn por la que IPv4 desafa las
predicciones de su propio fallecimiento. La traduccin dinmica de direcciones de red, NAT, permite a
una red utilizar un grupo de direcciones locales privadas sobre sus usuarios, y despus traducirlas a
direcciones pblicas, de esta manera, una pequea cantidad de direcciones pblicas, o incluso una sola,
es utilizada para dar servicio a una red local ms grande.
Para 1992, la rebautizada IAB, ahora Internet Architecture Board, reconoca el esfuerzo de ROAD
y mantena su idea acerca de una estrategia para el crecimiento de Internet. Su estrategia parta del
punto de que la siguiente generacin de IP sera CLNP (Connectionless Network Protocol). Este protocolo
es un elemento del modelo OSI definido por el estndar ISO 8473, que utiliza una arquitectura de
longitud variable en la asignacin de direcciones, donde la longitud de sta puede ser superior a los 160
bits [RFC 1347]. Para la IAB este era un paso importante, pero en julio de 1992 ante la IETF esta
propuesta no fue bien recibida.
16

Captulo 2

La idea que la IETF sostena no era un nuevo planteamiento en cuanto a que direccin seguir;
mas bien era, una redefinicin total y general de las estructuras y miembros de la organizacin en s,
incluyendo el IAB. Por supuesto un cambio tan estructural en la composicin, papeles y
responsabilidades de las estructuras se podran convertir en un problema sin un progreso definitivo.
Inmediatamente la IETF se embarc en un esfuerzo por emprender una revisin fundamental en el
protocolo del Internet y se esperaba tuviera como resultado encontrar o generar otro protocolo de alta
eficiencia tanto en ruteo como en direccionamiento. La IETF solicit tambin ayuda a varios sectores
de la industria, en general, para comprender las dimensiones de este proyecto, y crear un nuevo
protocolo. En 1994, el equipo de diseo del protocolo de siguiente generacin de la IETF, defini lo
que es el ncleo del protocolo IPv6. La caracterstica esencial de este protocolo era un refinamiento del
ya existente protocolo en su versin 4 (V4), que ms que una idea revolucionaria era otro enfoque
arquitectnico diferente de la V4.
IPv6 ha tenido una gran variedad de nombres - los documentos originales de IAB se refieren a l
como versin 7 de IP, ya que suponan que el nmero de protocolo 5 y 6 ya estaba en uso por redes de
investigacin (ver seccin 2.3). Cundo surgi de nuevo la duda sobre el nombre de IPv6, se sugiri
IPng, por next generation. Pero la ltima palabra sobre el nombre de IPv6 la tuvo la IANA (Internet
Assigned Numbers Authority) que indic que el nmero 6 para el protocolo estaba disponible; as pues, la
especificacin final fue nombrar con una versin 6 al Protocolo IP [HUS03].

2.4.1.DireccionesIPv6
El cambio ms drstico de IPv4 a IPv6 est sin duda en la longitud de las direcciones de red. Las
direcciones IPv6, definidas en el RFC 2373 y RFC 2374, son de 128 bits lo que corresponde a 32
dgitos hexadecimales que se utilizan normalmente para escribir las direcciones IPv6. Estas direcciones
estn compuestas por dos partes lgicas: un prefijo de 64 bits y otra parte de 64 bits que corresponde al
identificador de interfaz que casi siempre se genera automticamente a partir de la direccin MAC de la
interfaz a la que est asignada la direccin.

17

Captulo 2

Como se menciona en la seccin 2.4.3, existen tres tipos de direcciones: unicast, anyast y
multicast. El tipo especfico de estas direcciones IPv6 est indicado por los bits que encabezan la
direccin y se conoce como Formato de Prefijo (FP). La administracin de estas direcciones se organiza
en tres niveles de jerarqua:
Registro
Proveedor
Subscriptor
Este formato de direccin permite la distribucin flexible de direcciones a cada nivel de la
jerarqua de administracin de tal manera que se soporte la gran demanda durante la asignacin de
direcciones.
El formato de estos 128 bits, que aqu se trata, es de tipo unicast ya que es un tipo de direccin
que ms comnmente se utiliza. Esta direccin, maneja el prefijo 010 binario (el mismo formato de
direccin puede ser utilizado con otro prefijo mientras que la direccin siga siendo de tipo
unicast).Como se puede ver en la Figura 2.4 este formato de direccin consiste de las siguientes partes:
Formato de Prefijo (010)
ID de registro
ID de proveedor
ID de subscriptor
Intra-subscriptor (este es definido directamente por el subscriptor)
3

5 bits

n bits

56-n bits

64 bits

010

ID de registro

ID de proveedor

ID de subscriptor

Intra-subscriptor

Figura 2.4: Formato de direccin de 128 bits [RFC 2073].

Para mayor referencia acerca de cmo es utilizado este formato de 128 bits se recomienda
consultar el RFC 2073.

18

Captulo 2

ID de registro: Este valor pretende facilitar una fcil distribucin geogrfica de direcciones
para facilitar la operacin de los RIR. Este identificador va inmediatamente despus del Formato
de Prefijo y es parte de la direccin IPv6.
ID de proveedor y ID de subscriptor: Estas direcciones son asignadas por registro de
manera individual. Estos registros definen cuanto espacio de direcciones va a ser asignado al
proveedor y a sus subscriptores.
Intra-subscriptor: Esta porcin de la direccin se deja que sea asignada directamente por los
subscriptores individuales.
Se espera que este formato de direccin sea ampliamente utilizado por nodos IPv6 conectados a
Internet.

2.4.1.1NotacinparalasdireccionesIPv6
La representacin de las direcciones se hace en cadenas de texto del tipo:
x:x:x:x:x:x:x:x
donde cada x es un valor hexadecimal de 16 bits, de cada uno de los 8 campos que definen la direccin.
Por ejemplo:
2001:0db8:85a3:08d3:1319:8a2e:0370:7334
es una direccin IPv6 vlida.
Pero existen tres formas convencionales de representar estas direcciones:
1.

La ms popular de ellas es la cadena ya antes mencionada:

x:x:x:x:x:x:x:x

2.

Dado que en IPv6 es comn encontrar largas cadenas de ceros, si un grupo de cuatro dgitos es
nulo (es decir, toma el valor "0000"), la direccin puede ser comprimida. Por ejemplo,

19

Captulo 2

2001:0db8:85a3:0000:1319:8a2e:0370:7344
es la misma direccin que
2001:0db8:85a3::1319:8a2e:0370:7344
El uso de :: indica que uno o mas grupos de 16 bits son cero; pero, si la direccin contiene ms de
una serie de grupos nulos consecutivos la compresin slo ser valida para uno de ellos. As:
2001: 0000:0DB8: 0000: 1428:0000: 57ab: 1403
2001: 0000:0DB8: 0000: 1428:: 57ab: 1403
Cuando se tiene el caso en que ms de una cadena nula (0000), existe la opcin de representarlas
mediante la compresin, por ejemplo:
2001:0DB8:0000:0000:0000:0000:1428:57ab
2001:0DB8:0:0:0:0:1428:57ab
Otra opcin vlida, es el uso de la notacin :: :
2001:0DB8::1428:57ab
Los ejemplos anteriores son vlidas y significan lo mismo, pero por ejemplo:
2001::25de::57ab
no es vlido ya que no queda claro cuantos grupos nulos hay en cada lado.
Los ceros iniciales en un grupo pueden ser omitidos tambin. Por ejemplo:
es lo mismo que:
3.

2001:0DB8:02de::0e13

2001:DB8:2de::e13
Otra manera forma alternativa, quizs la ms conveniente de ellas, cuando se tiene un ambiente
mixto de nodos IPv4 e IPv6. Para escenarios con este tipo de ambientes, es posible utilizar la
siguiente sintaxis: x:x:x:x:x:x:d.d.d.d, donde x representa valores hexadecimales de las seis

20

Captulo 2

primeras partes ms significativas (de 16 bits cada una) que componen la direccin y las d, son
valores decimales de las 4 partes menos significativas (de 8 bits cada una que representan las
direcciones IPv4 estndar). Por ejemplo:
::FFFF:129.144.52.38
donde 129.144.52.38 representa a una direccin IPv4. El formato anterior se denomina direccin
IPv4 mapeada, y el formato ::1.2.3.4 direccin IPv4 compatible.

2.4.2.Tiposdedirecciones
De acuerdo al RFC 2732, existen tres tipos de direcciones:
Unicast: identifican a una sola interfaz (comunicacin uno-uno).
Multicast: que identifican un grupo de interfaces (direcciones de grupo).
Anycast: identifican a un conjunto de interfaces (similar a multicast)
Los tipos de direcciones IPv6 pueden identificarse tomando en cuenta los bits de mayor orden
como sigue
Tabla 2.2: Tipo de direcciones IPv6 basadas en las establecidas por el RFC 3513.
Tipo de Direccin

Prefijo (binario)

Notacin IPv6

No especificada

00...0 (128 bits)

::/128

Loopback

00...1 (128 bits)

::1/128

Multicast

11111111

FF00::/8

Unicast (Link-local)

1111111010

FE80::/10

Unicast (Site-local)

1111111011

FEC0::/10

Unicast global

(lo restante)

Como es de notarse, IPv6 no maneja direcciones de broadcast, ya que su funcionalidad ha sido

mejorada por las direcciones multicast [RFC 2375]. La ventaja a esto, es que los sistemas que no estn
interesados en cierta informacin no son forzados a dedicar ciclos de trabajo recibindolos. La
funcionalidad de las direcciones de broadcast pueden emularse utilizando la de tipo multicast FF01::1,
denominada all nodes.
21

Captulo 2

Por otro lado, las direcciones multicast y anycast pueden utilizarse como direcciones destino,
pero slo las de tipo unicast pueden ser utilizadas como direcciones fuente.
Una direccin IPv6 identifica especficamente una interfaz ms que a un usuario o nodo como
en IPv4. Esto no es un hecho revolucionario como podr parecer desde que usuarios que pertenecen a
diferentes subredes (multi-homed host) son comunes en redes IPv4, con cada puerto perteneciendo a una
subred diferente.
Como en IPv4, en IPv6 tambin existe una jerarqua de direcciones, sta es considerablemente
ms compleja que la jerarqua de las clases A/B/C de IPv4, que es descrita va una anotacin adicional
para dirigir los fragmentos de direcciones que son representado normalmente por / y un conteo de
los bits significativos. Por ejemplo, la notacin 5A00::/8 significa que el grupo de direcciones IPv6
comienza con los 8bits. A continuacin una Tabla con las jerarquas para IPv6:
Tabla 2.3: Jerarquas de direcciones establecidas para IPv6. Como se puede notar la gran mayora de
ellas no est asignada an.
Direccin

Prefijo (binario)

Uso

::/3

000

Uso especial

0::/8

0000 0000

Reservada

2000::/3

001

No asignada

8000::/3

100

Basado geogrficamente

FE90::/10

1111 1110 10

Enlace Local

FEC0::/10

1111 1110 11

Sitio Local

FF00::/8

1111 1111

Multicast

2.4.3Prefijos
La representacin de prefijos en subredes, ruteadores y rangos de direcciones IPv6 son expresados de la
misma forma que la notacin CIDR utilizada en IPv4. Un prefijo de direccin IPv6 se representa con la
siguiente notacin: direccin-IPv6/longitud-prefijo, donde direccin-IPv6 es una direccin IPv6
en cualquiera de las notaciones mencionadas anteriormente, mientras que longitud-prefijo representa un

22

Captulo 2

valor decimal que indica cuntos de los bits ms significativos comprenden al prefijo [RFC 3515]. Por
ejemplo:
12AB:0000:0000:CD30:0000:0000:0000:0000/60
es una direccin IPv6 con un prefijo de 60. Esto quiere decir que los primeros 60 bits representan la
subred, el cual tendra un prefijo de:
12AB00000000CD3
Como en todas la situaciones, hay caso no vlidos para representar a los prefijo. Estos casos se
muestran a continuacin:
12AB:0:0:CD3/60 ya que puede no tomar en cuenta los ceros iniciales (en este caso el cero antes de
CD3).
12AB::CD30/60

la direccin a la izquierda de / se expande de la siguiente manera :

12AB:0000:0000:0000:0000:000:0000:CD30

12AB::CD3/60

que tendra una representacin de la siguiente manera:

12AB:0000:0000:0000:0000:000:0000:0CD3
Cuando se escriben tanto la direccin del nodo, como su prefijo se utiliza la siguiente forma:
Si la direccin del nodo es:
y su nmero de subred:

12AB:0:0:CD30:123:4567:89AB:CDEF
12AB:0:0:CD30::/60

esto se puede abreviar como: 2AB:0:0:CD30:123:4567:89AB:CDEF/60

2.4.4Encabezadodered
El tamao del encabezado del protocolo IPv6 es de 320 bits o 40 bytes, el doble de lo que hay en la
versin 4. Sin embargo, este nuevo encabezado se ha simplificado con respecto al anterior. Algunos
campos se han retirado de la misma, mientras que otros se han convertido en opcionales por medio de
las extensiones (como es el caso de la Fragmentacin, y Tipo de Servicio). Es muy importante
23

Captulo 2

remarcar, que de esta manera los ruteadores no tienen que procesar parte de la informacin del
encabezado o header, disminuyendo el tiempo de procesamiento. El formato completo de la cabecera
sin las extensiones es el siguiente [GOR98]: (ver Figura 2.5).
Versin

Prioridad

(8 bits)

(8 bits)

Etiqueta de flujo (24 bits)

Siguiente
cabecera

Longitud (6 bits)

(8 bits)

Lmite de
salto
(8 bits)

Direccin de origen (128 bits)

Direccin de destino (128 bits)
Figura 2.5: Encabezado IPv6.

Sus campos se definen a continuacin:

1.

Versin: Este grupo de bits es siempre de 0110 (6 decimal). Este mismo grupo de cuatro
bits est en 0100 (4 decimal) para IPv4. As que, cualquier paquete puede ser fcilmente
distinguido (4 bits).

2.

Prioridad: Este nmero est entre el rango de 0-15 y especifica, como lo indica su nombre,
la prioridad del paquete. IPv6 divide el trfico en dos categoras, congestin-controlada y
congestin no-controlada. El Trfico de congestin- controlada puede ser arbitrariamente
retrasada si la red est congestionada, mientras que el trfico no-controlado no puede ser
retrasado y debe ser descartado. ste ltimo est tpicamente asociado con aplicaciones tales
como video y audio en tiempo-real.

3.

Etiqueta de flujo: Campo que se utiliza para indicar que el paquete requiere un tratamiento
especial por parte de los ruteadores que lo soporten. Este valor puede ser utilizado para
identificar el tipo de flujo de trfico y provee la capacidad de ruteo de trfico especfico a un
flujo en particular va una ruta en determinada. Tambin se puede simplificar el proceso de
ruteo, manteniendo el rastro de a donde va la fuente/destino del flujo y hacer una bsqueda
en tablas. Estas etiquetas aun estn en etapa experimental (24 bits).

24

Captulo 2
4.

Longitud efectiva de Datos: Es la longitud en bytes de los datos efectivos que se

encuentran a continuacin del encabezado (permitiendo valores de hasta 65 535). Junto con
el tamao del encabezado, proporciona el tamao del datagrama (6 bits).

5.

Siguiente encabezado: Se utiliza para indicar el protocolo al que corresponde el

encabezado que se sita a continuacin del encabezado bsico. El valor que puede tomar este
campo es el mismo que el que se maneja en la versin 4 de IP (8 bits).

6.

Lmite de salto (Hop): Tiene el mismo propsito que el campo de la versin 4, y es un

valor que disminuye en una unidad cada vez que el paquete pasa por un nodo. Determinar que
tan lejos viaja un datagrama y es utilizado para prevenir el ciclado de stos (8 bits).

7.

Direccin de origen: El nmero de direccin del host que enva el paquete. Su longitud es
cuatro veces mayor que en la versin 4 (128 bits).

8.

Direccin de destino: Nmero de direccin de destino, aunque puede no coincidir con la

direccin del host final en algunos casos. Su longitud es cuatro veces mayor que en la versin 4
del protocolo IP (128 bits).
Los datos situados en los encabezados de tipo opcional (Encabezados de Extensin) se procesan

slo cuando el mensaje llega a su destino final, lo que supone una mejora en el rendimiento y tiempo de
procesamiento. Otra ventaja adicional es que el tamao del encabezado no est limitado a un valor fijo
de bytes como ocurra en la versin 4. Por razones de eficiencia, las extensiones del encabezado
siempre tienen un tamao mltiplo de 8 bytes. Actualmente se encuentran definidas extensiones para
routing extendido, fragmentacin y ensamble, seguridad, confidencialidad de datos, etc [GOR98].
Debido a la similitud entre los encabezados del Protocolo de Internet Versin 4 y Versin 6
(IPv4/IPv6), se puede considerar el decir que trabajan casi de la misma manera y que hablan el mismo
lenguaje. Es por esto que se puede trabajar con mayor transparencia, en cuanto al trabajo conjunto
con otros protocolos de capas superiores o inferiores de TCP/IP y otros protocolos que asisten durante
el procesamiento de la informacin.
Como es sabido, IPv6 es una versin sucesora del Protocolo de Internet Versin 4, por lo tanto
las modificaciones entre estas dos versiones del mismo protocolo se encuentran en lo siguiente:

25

Captulo 2

Simplificacin en el formato del encabezado

Capacidad de direccionamiento extendido
Capacidad de Etiquetamiento de Flujo
Capacidad de Autenticacin y Privacidad
Soporte mejorado para Extensiones y Opciones dentro del encabezado [RFC 2460]

2.5SistemadeNombredeDominio(DNS)
Las direcciones IPv6 se representan en el Sistema de Nombres de Dominio (DNS) mediante registros
AAAA (tambin llamados registros de quad-A, por analoga con los registros A para IPv4). El concepto
de AAAA fue una de las dos propuestas al tiempo que la arquitectura IPv6 estaba siendo diseada. La
otra propuesta utilizaba registros A6 y otras innovaciones como las etiquetas de cadena de bits y los
registros DNAME. La idea de A6 fue una revisin y puesta a punto del DNS para ser ms genrico, de
ah su complejidad, mientras que la idea de AAAA es una simple generalizacin del DNS IPv4. El RFC
3363 recomienda utilizar registros AAAA hasta que se pruebe y estudie exhaustivamente el uso de
registros A6. El RFC 3364 realiza una comparacin de las ventajas y desventajas de cada tipo de
registro.

2.6Resumen
Adoptado por el Internet Engineering Task Force en 1994 (cuando era llamado "IP Next Generation" o
IPng), IPv6 cuenta con un pequeo porcentaje de las direcciones pblicas de Internet, que todava estn
dominadas por IPv4. IPv6 es la versin sucesora del Protocolo de Internet que se ha adoptado para uso
general. Tambin hubo un IPv5, pero no fue un sucesor de IPv4; mejor dicho, fue un protocolo
experimental orientado al flujo que intentaba soportar voz, video y audio.
Aunque la adopcin de NAT alivia parcialmente el problema de la falta de direcciones IP, pero
una de las desventajas de esta adopcin hace difcil o imposible el uso de algunas aplicaciones P2P (Peerto-Peer) como voz sobre IP (VoIP) y juegos multiusuario. La ventaja de tener campos de direcciones ms

26

Captulo 2

largos es que entonces no haya la necesidad forzada de utilizar NAT como traductor de direcciones para
aumentar el valor escalar de direcciones en la red.
Un paquete IPv6 est constituido principalmente de dos partes: el encabezado y los datos. El
encabezado tiene una longitud de 40 bytes, y est compuesto por los siguientes campos: Versin de IP
(4 bits), Clase de Trfico (8 bits, denota la prioridad del paquete), Etiqueta de Flujo (20 bits, maneja la
Calidad de Servicio), Longitud del Campo de datos (16 bits), Encabezado Siguiente (8 bits), Lmite de
Salto (8 bits), Direccin origen y Direccin destino de 128 bits cada una. La Tabla 2.6 muestra las
diferencias bsicas entre el encabezado IPv4 y su sucesor IPv6.
Tabla 2.6: Encabezados bsicos de IPv4 e IPv6.
IPv4

IPv6

20 octetos de encabezado

40 octetos de encabezado

12 campos

8 campos

4 octetos (32 bits) de direcciones

16 octetos (128 bits) de direcciones

Calidad de Servicio especificado en el campo

Calidad de Servicio especificado en la Etiqueta

de Tipo de Servicio:

de Flujo y Clase de Trfico:

Originalmente:

Tipo de Servicio (5 bits)

Originalmente:

Clase de Trfico (nunca utilizado)

Prioridad (3 bits)
Opciones Limitadas (raramente utilizadas)

Sistema

de

(significante

encabezados

nmero

de

extensibles

paquetes

tendrn

encabezados de extensin)
Fragmentacin de paquetes en ruteadores.

Fragmentacin de paquetes slo en el nodo

Informacin de fragmentacin contenida en el

fuente.

encabezado principal (campo siempre

Informacin de fragmentacin contenida en el

presente)

encabezado de extensin (presente slo si es

necesitado)

Checksum del encabezado

No checksum

TTL (originalmente se supona que fuera en

Salto (ahora por saltos)

unidades de tiempo).

Longitud total (comprende el tamao del

Longitud total (el tamao del encabezado es fijo

encabezado ms el de la carga)

y el resto depende de los encabezados de

Extensin)

27

Captulo 2

La representacin de las direcciones IPv6 se hace en cadenas de texto del tipo: x:x:x:x:x:x:x:x
donde cada x representa a un valor hexadecimal de 16 bits, de cada uno de los 8 campos que definen la
direccin. Un ejemplo de estas direcciones es:
01:0db8:85a3:08d3:1319:8a2e:0370:7334
En nuestros das, el gran catalizador de IPv6 es la capacidad de ofrecer nuevos servicios como la
movilidad, Calidad de Servicio (QoS), privacidad, etc. Pero no es slo esto, si no la capacidad de IPv6
de ofrecer una respuesta a la escasez de direcciones, por lo que se piensa utilizar.
De manera leve se puede ver a IPv6 como una tentativa para recobrar el propsito original de IP
para que d un simple y uniforme servicio de red que proporcione flexibilidad en aplicaciones de punta
a punta. A menudo hay casos en que arquitecturas complejas no son escalables, y desde esta perspectiva
IPv6 aparenta ser todo lo contrario. Se espera que IPv4 se siga soportando hasta por lo menos el 2025,
ya que hay muchos dispositivos que aun no se migrarn a IPv6 y que seguirn siendo utilizados por
mucho tiempo.

28