Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
6Activity
0 of .
Results for:
No results containing your search query
P. 1
IPv6 Principios

IPv6 Principios

Ratings: (0)|Views: 749|Likes:
Published by infobits

More info:

Published by: infobits on May 10, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as TXT, PDF, TXT or read online from Scribd
See more
See less

02/26/2013

pdf

text

original

IPv6 Principios tecnol gicos
\ufffd
01/06/2000 Jordi Palet. http://consulintel.es
Aqu se expone una primera aproximaci n a los principios fundamentales de IPv6,
\ufffd
\ufffd
especialmente en lo que se refiere a sus especificaciones b sicas (RFC2460), y a
\ufffd
las cuestiones que afectan a las direcciones y los direccionamientos (RFC2373).
Para facilitar su comprensi n, hemos optado por adoptar un esquema de tutorial.
\ufffd
Dada la amplitud del tema, se trata tan s lo de una primera entrega sobre los
\ufffd
principios tecnol gicos del nuevo IP. Otros aspectos ir n siendo desarrollados,
\ufffd
\ufffd
como art culos independientes pero relacionados, en pr ximos n meros.
\ufffd
\ufffd
\ufffd
ESPECIFICACIONES BASICAS
Veamos, en primer lugar, la descripci n de la cabecera
\ufffd
de un paquete IPv4:
+---------------------------------------------------------+
| +Version |*Header |+TOS |
+Total Lenght

| +---------------------------------------------------------+ |

*Identification
|*Flag |
*Fragment Offset

| +---------------------------------------------------------+ |

+TTL
| +Protocol |
*Checksum
|
+---------------------------------------------------------+
Como vemos, la longitud m nima de la cabecera IPv4 es de 20
\ufffd
bytes (cada fila de la tabla supone 4 bytes). A ello hay que a adir las
\ufffd

opciones, que dependen de cada caso. En la tabla anterior hemos usado abreviaturas, en aquellos casos en los que son comunes. En el resto, se ha optado por nuestra

particular
traducci n de la nomenclatura
original
\ufffd
\ufffd
\ufffd
anglosajona, cuya leyenda de equivalencias indicamos a continuaci n:
\ufffd
\ufffd
\ufffd
- Version
Versi n (4 bits)
\ufffd
\ufffd
- Header
Cabecera (4 bits)
\ufffd
- TOS (Type Of Service)
Tipo de Servicio (1 byte)
\ufffd
- Total Length
Longitud Total (2 bytes)
\ufffd
- Identification
Identificaci n (2 bytes)
\ufffd
\ufffd
- Flag
Indicador (4 bits)
\ufffd
- Fragment Offset
Desplazamiento de Fragmentaci n (12 bits
1.5 bytes)
\ufffd
\ufffd
\ufffd
- TTL (Time To Live)
Tiempo de Vida (1 byte)
\ufffd
- Protocol
Protocolo (1 byte)
\ufffd
- Checksum
C digo de Verificaci n (2 bytes)
\ufffd
\ufffd
\ufffd
- 32 bit Source Address
Direcci n Fuente de 32 bits (4 bytes)
\ufffd
\ufffd
- 32 bit Destination Address
Direcci n Destino de 32 bits (4 bytes)
\ufffd
\ufffd
En la tabla anterior, hemos marcado, mediante el color de fondo, los campos que
van a desaparecer en IPv6, y los que son modificados, seg n el siguiente
\ufffd
esquema:
Campo modificado = +
Campo que desaparece = *

En el nuevo IP, se ha pasado de tener 12 campos, como en IPv4, a tan solo 8. El motivo fundamental por el que los campos son eliminados es la innecesaria redundancia. En IPv4 se facilita la misma informaci n de varias formas. Un caso

\ufffd
muy evidente es el checksum o verificaci n de la integridad de la cabecera, cuya
\ufffd
funci n ya es realizada por otros mecanismos de encapsulado (IEEE 802 MAC,
\ufffd
framing PPP, capa de adaptaci n ATM, etc.). El caso del campo de Desplazamiento
\ufffd
\ufffd
de Fragmentaci n , es ligeramente diferente, dado que el mecanismo por el que se
\ufffd \ufffd
realiza la fragmentaci n de los paquetes se ha modificado totalmente en IPv6, lo
\ufffd
que implica la total
inutilidad de este campo. En IPv6 los encaminadores no
\ufffd
\ufffd
fragmentan
los
paquetes,
sino
que
de
ser
precisa,
dicha
fragmentaci n/desfragmentaci n se produce extremo a extremo.
\ufffd
\ufffd
Algunos de los campos han adoptado otras denominaciones: - Longitud total:
longitud de carga til (payload length). Es, en definitiva, la longitud de los
\ufffd
propios datos, y puede ser de m s de 65.536 bytes. Tiene una longitud de 16 bits
\ufffd

(2 bytes). - Protocolo: siguiente cabecera (next header). Dado que en lugar de usar cabeceras de longitud variables se emplean sucesivas cabeceras encadenadas, desaparece el campo de opciones. En muchos casos ni siquiera es procesado por los encaminadores, sino tan s lo extremo a extremo. Tiene una longitud de 8 bits

\ufffd
(1 byte). - Tiempo de vida: l mite de saltos (Hop Limit). Tiene una longitud de
\ufffd
8 bits (1 byte).
Los nuevos campos son: - Clase de Tr fico (Traffic Class), tambi n denominado
\ufffd
\ufffd
Prioridad (Priority), o simplemente Clase (Class). Podr a ser m s o menos
\ufffd
\ufffd
equivalente a TOS en IPv4. Tiene una longitud de 8 bits (1 byte). - Etiqueta de
Flujo (Flow Label), para permitir tr ficos con requisitos de tiempo real. Tiene
\ufffd
una longitud de 20 bits.
Estos dos campos, como se puede suponer, son los que nos permiten una de las
caracter sticas fundamentales e intr nsecas de IPv6: Calidad de Servicio (QoS),
\ufffd
\ufffd
Clase de Servicio (CoS), y en definitiva un poderoso mecanismo de control de
flujo, de asignaci n de prioridades diferenciadas seg n los tipos de servicios.
\ufffd
\ufffd
Por tanto, en el caso de un paquete IPv6, la cabecera tendr a el siguiente
\ufffd
formato: El campo de versi n, que es igual a 6, l gicamente, tiene una longitud
\ufffd
\ufffd

de 4 bits. La longitud de esta cabecera es de 40 bytes, el doble que en el caso de IPv4, pero con muchas ventajas, al haberse eliminado campos redundantes. Adem s, como ya se ha mencionado, la longitud fija de la cabecera implica una

\ufffd

mayor facilidad para su procesado en routers y conmutadores, incluso mediante hardware, lo que implica unas mayores prestaciones. A este fin coadyuva, como hemos indicado anteriormente, el hecho de que los campos est n alineados a 64

\ufffd
bits, lo
que permite
que las
nuevas generaciones
de procesadores y
microcontroladores, de 64 bits, puedan procesar mucho m s eficazmente la
\ufffd
cabecera IPv6. El valor del campo siguiente cabecera , indica cual es la
\ufffd
\ufffd
siguiente cabecera y as
sucesivamente. Las sucesivas cabeceras, no son
\ufffd
examinadas en cada nodo de la ruta, sino s lo en el nodo o nodos destino
\ufffd
finales. Hay una nica excepci n a esta regla: cuando el valor de este campo es
\ufffd
\ufffd
cero, lo que indica opci n de examinado y proceso salto a salto
(hop-by-hop).
\ufffd
\ufffd
\ufffd
As
tenemos, por citar
algunos ejemplos, cabeceras con
informaci n de
\ufffd
\ufffd
encaminado, fragmentaci n, opciones de destino, autenticaci n, encriptaci n,
\ufffd
\ufffd
\ufffd
etc., que en cualquier caso, han de ser procesadas en el orden riguroso en que
aparecen en el paquete. Sin entrar en m s detalles, v anse a continuaci n los
\ufffd
\ufffd
\ufffd
siguientes ejemplos gr ficos del uso del concepto de las
cabeceras de
\ufffd
\ufffd
extensi n (definidas por el campo
siguiente cabecera ), mecanismo por el que
\ufffd \ufffd
\ufffd
\ufffd
cada cabecera es
encadenada a la siguiente y anterior (si existen): El MTU
\ufffd
\ufffd
(Unidad M xima de Transmisi n) debe de ser como m nimo, de 1.280 bytes, aunque
\ufffd
\ufffd
\ufffd
se recomiendan tama os superiores a 1.500 bytes. Los nodos descubren el valor
\ufffd
MTU a trav s de la inspecci n de la ruta. Se prev as una optimizaci n de los
\ufffd
\ufffd
\ufffd
\ufffd
\ufffd
paquetes y del n mero de cabeceras, dado el continuo crecimiento de los anchos
\ufffd
de banda disponibles, as como del incremento del propio tr fico. Dado que IPv6
\ufffd
\ufffd
no realiza verificaci n de errores de la cabecera en tr fico UDP, se requiere el
\ufffd
\ufffd
empleo del su propio mecanismo de checksum.
DIRECCIONES Y DIRECCIONAMIENTO

Ya hemos dicho que IPv6 nos aporta, como principio fundamental, un espacio de direcciones de 2 elevado a 128, lo que equivale a 3,40 elevado a 38 (340.282.366. 920.938.463.463.374.607.431.768.211.456).

Definici n de direcci n en IPv6 Las direcciones IPv6 son identificadores de 128
\ufffd
\ufffd
bits para interfaces y conjuntos de interfaces. Dichas direcciones se clasifican
en tres tipos:
- Unicast: Identificador para una
nica interfaz. Un paquete enviado a una
\ufffd
direcci n unicast es entregado s lo a la interfaz identificada con dicha
\ufffd
\ufffd
direcci n. Es el equivalente a las direcciones IPv4 actuales.
\ufffd
- Anycast: Identificador
para un
conjunto
de
interfaces (t picamente
\ufffd
pertenecen
a diferentes nodos). Un
paquete enviado a una direcci n anycast
\ufffd
es entregado en una (cualquiera) de las interfaces identificadas
con dicha
direcci n (la m s pr xima, de acuerdo a las medidas de distancia del protocolo
\ufffd
\ufffd
\ufffd
de routing). Nos permite crear, por ejemplo, mbitos de redundancia, de forma
\ufffd
que varias m quinas puedan ocuparse
del mismo tr fico seg n una
secuencia
\ufffd
\ufffd
\ufffd
determinada (por el routing), si la primera cae .
\ufffd
\ufffd
- Multicast: Identificador para un conjunto de interfaces (por lo
general
pertenecientes a diferentes
nodos). Un paquete enviado a una
direcci n
\ufffd
multicast es entregado a
todas las
interfaces identificadas
por dicha
direcci n. La misi n de este tipo de paquetes es evidente: aplicaciones de
\ufffd
\ufffd
retransmisi n m ltiple (broadcast).
\ufffd
\ufffd
Diferencias con IPv4
Hay algunas diferencias importantes en el direccionamiento de
IPv6 respecto
de IPv4:
- No
hay direcciones
broadcast (su
funci n es sustituida por
\ufffd
direcciones multicast).
-
Los campos de las direcciones reciben nombres espec ficos; denominamos
\ufffd
prefijo a la parte de la direcci n hasta el nombre indicado (incluy ndolo).
\ufffd
\ufffd
\ufffd
\ufffd
- Dicho prefijo nos permite conocer d nde
esta conectada una determinada
\ufffd
direcci n, es decir, su ruta de encaminado. Cualquier campo puede contener s lo
\ufffd
\ufffd
ceros o s lo unos, salvo que expl citamente se indique lo contrario.
\ufffd
\ufffd
- Las direcciones IPv6, indistintamente de su tipo
(unicast, anycast o
multicast), son asignadas a interfaces,
no nodos. Dado que
cada interfaz
pertenece a un nico nodo, cualquiera de las direcciones unicast de las
\ufffd
interfaces del nodo puede ser empleado para referirse a dicho nodo.
- Todas las interfaces han de tener, al menos, una direcci n unicast link
\ufffd
-local (enlace local).
- Una nica interfaz puede tener tambi n varias direcciones IPv6 de
\ufffd
\ufffd
cualquier tipo (unicast, anycast o multicast) o mbito. Una misma direcci n o
\ufffd
\ufffd
conjunto de direcciones unicast pueden ser asignados a m ltiples interfaces
\ufffd
f sicas, siempre que la implementaci n trate dichas interfaces desde el punto de
\ufffd
\ufffd
vista de internet, como una
nica, lo que permite balanceo de carga entre
\ufffd
m ltiples dispositivos.
\ufffd
- Al igual que en IPv4, se asocia un prefijo de subred con un enlace, y
se
pueden asociar m ltiples prefijos de subred a un mismo enlace.
\ufffd
Reservas de espacio de direccionamiento en IPv6
A diferencia de las asignaciones de
espacio de
direccionamiento que
se
hicieron en IPv4, en
IPv6, se ha reservado, que no asignado , algo m s
\ufffd
\ufffd
\ufffd
del 15%, tanto para permitir una f cil transici n (caso del
protocolo IPX)
\ufffd
\ufffd
como para
mecanismos requeridos
por el propio protocolo. De esta forma se
permite la asignaci n directa de
direcciones de agregaci n, direcciones
\ufffd
\ufffd
locales, y direcciones multicast, con reservas para OSI NSAP e IPX. El 85%

Activity (6)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
fcoalderete liked this
Tirso Alejandro liked this
Remigio Hurtado liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->