Você está na página 1de 8

El protocolo IP

RFC tiles :

RFC791 - Internet Protocol - Septiembre 1981;


RFC1122 - Requirements for Internet Hosts - Communication Layers - Octubre
1989.

IP es el protocolo de la capa Internet. Es el nico protocolo de la capa 3 utilizado en


Internet. Existen otros protocolos de la capa 3 que garantizan un servicio parecido:

IPX, Internetwork Packet eXchange, el protocolo de la marca Novell, para su red


Netware.
Appletalk, utilizado durante mucho tiempo en los ordenadores Macintosh, de la
marca Apple.

Estos dos protocolos, que ofrecen soluciones tcnicas interesantes, fueron sustituidos por IP
en un movimiento de convergencia que hemos llamado IP Everywhere.
La UIT (Unin Internacional de Telecomunicaciones), ha desarrollado sus propias
especificaciones: el servicio CLNS (Connection Less Network Service), est implementado
en el protocolo de la capa de red CLNP (Connection Less Network Protocol) y se utiliza
por el protocolo de transporte TP4 (Transport Protocol Class 4). La ventaja de CLNP es
proporcionar un espacio de direccionamiento mayor que IPv4, con las direcciones
expresadas en 20 bytes. IPv6 sirvi de base para la propuesta TUBA, candidata a la
sucesin de IPv4. Parece obvio que estos protocolos permanecern para siempre en fase de
especificaciones.
La funcin principal que garantiza el protocolo IP es el encaminamiento a travs de la
malla de red, actividad inseparable del enrutamiento. IP funciona en modo desconectado y
garantiza un servicio de entrega de los datagramas de tipo Best effort, hace todo lo
posible para garantizar su misin y no tiene la capacidad de gestionar los paquetes no
entregados, duplicados, sin secuencia o corruptos. Para conseguir un diseo confiable del
protocolo IP, fue necesario utilizar cabeceras ms pesadas en todos los intercambios que
transitan por la red. Adems, los routeres debieron asumir una mayor complejidad. Ahora
bien, no todos los intercambios que transitan por la red necesitan esta confiabilidad. El
transporte de flujos de informacin en tiempo real (voz o vdeo), tienen otros
requerimientos (retardo, banda ancha, etc.), para los cuales la bsqueda de esta
confiabilidad, podra llegar a ser contraproducente.
La palabra datagrama, utilizada para hacer referencia al paquete IP, recuerda esta falta de
fiabilidad. Son los diseadores de Internet los que tomaron la opcin de trasladar la
bsqueda de esta fiabilidad a los host de los extremos y por lo tanto, en la capa de
Transporte, en lo que se ha llamado el control de punto a punto o de principio a fin. Cada
datagrama se encamina por la red de manera independiente al resto de datagramas, ya que

cada uno tiene, al mismo tiempo, informacin sobre su direccin de origen y su direccin
de destino.
IP se basa en las redes existentes. El transito del paquete por el medio elegido incumbe a la
capa de Enlace. De nuevo, el principio de independencia de las capas parece que se respeta,
aunque sin embargo hay una pega: la trama de la capa de Enlace no puede aceptar cualquier
tamao de paquete (MTU). De la misma manera que un guante se adapta a una mano, la
capa de red se debe adaptar a la capacidad de la capa de Enlace y aprender esta informacin
MTU:

De esta manera, en el ejemplo anterior, debido a que el MTU del enlace entre los routeres
es inferior al correspondiente a las redes locales que soportan los PC, IP del router R1
fragmenta los datos que salen de PC1 o PC2 cuando estos se destinan a PC3 o PC4. De la
misma manera, IP del router R2 fragmenta los datos que salen de PC3 o PC4 cuando estos
van destinados a PC1 o PC2.
Lo que es necesario recordar es lo siguiente:
IP proporciona un servicio de entrega:

en modo no conectado;
cuya unidad de datos, llamada datagrama, se asocia a un formato de paquete;
cuya actividad principal consiste en encaminar los paquetes, siendo sta una
actividad distribuida, ya que cada nodo de la red (router), intenta acercar el
datagrama de su destino;
enmarcado por una serie de normas (el vnculo), que especifican el
comportamiento de los host y de los routeres durante el tratamiento de los paquetes:
creacin de mensajes de error, accin papelera

1. El datagrama IP

a. Campo Version

b. Campo IHL (Internet Header Length)

Aqu est el detalle de los diferentes campos. Los campos ms importantes, se


resaltan mediante ( campo clave)
nico campo que ocupa la misma posicin en el formato IPv4 y en el formato IPv6.
El nmero de versin del protocolo IP es 4 o 6, expresado en 4 bits.

Longitud del encabezado del paquete IP, necesario porque hay un campo Options de
longitud variable. Gracias al campo IHL, IP puede determinar dnde termina el encabezado
y dnde comienzan los datos. Atencin, el valor se expresa en unidades de 32 bits, lo que
implica que la longitud del encabezado es obligatoriamente mltiplo de 32, ver tambin el
campo Atasco. La longitud del encabezado mnimo se establece en 20 bytes (opcin cero).
El valor contenido en el campo IHL est limitado a 15 (4 bits) y la longitud mxima del

encabezado correspondiente a 60 bytes (40 bytes de opciones). Por tanto, al final, el valor
del campo IHL, est comprendido entre 5 y 15.

c. Campo TOS (Type Of Service) ( campo clave)


Atencin, muchos de los documentos circulan con una definicin de este campo
desactualizada. En efecto, el campo TOS ya ha pasado por tres versiones, propuestas en los
RFC siguientes:

la versin del RFC791, que describe el protocolo IP;


RFC2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers - Diciembre de 1998;
RFC3168 - The Addition of Explicit Congestion Notification (ECN) to IP Septiembre de 2001.

Este campo tambin existe en el encabezado IPv6, pero se convierte en el campo Clase de
trfico.
El contenido de este campo, tal y como se define en el RFC791, es el siguiente:

La ilustracin siguiente muestra el contenido actual del byte TOS:

Qu sucede cuando un router no puede trasmitir los paquetes que recibe? En condiciones
normales, se pueden producir rfagas de los paquetes, cuyo ritmo supera la capacidad de
procesamiento del router. Estos paquetes se ubican en la cola de espera y el router viene a
buscarlos de manera secuencial y a su ritmo. Por supuesto, el sistema tiene un lmite. Un
flujo de entrada demasiado grande puede provocar la saturacin de estas colas de espera. A
este fenmeno se le llama congestin. Inevitablemente, el router est forzado a eliminar
paquetes y puede hacerlo de manera aleatoria (es la nocin de Best effort), aunque con la
ayuda del campo DS (Differentiated Services), es posible hacerlo de manera ms
inteligente. La idea es crear clases de trfico, caracterizadas por una probabilidad de
rechazo. Las clases mayores corresponden a una probabilidad de rechazo menor.
El RFC2474 define la nocin de PHB (Per Hop Behaviour), difcil de traducir que consiste
en definir el comportamiento del router en la transmisin de los paquetes, segn el nivel de
prioridad DSCP (Differentiated Services Code Point), contenido en el campo DS. El valor
DSCP 000000 slo garantiza el comportamiento por defecto de tipo Best Effort.
Para los paquetes que necesitan un tratamiento incluso Best los RFC 2597 y 2598
proporcionan los valores de DSCP para dos tipos de comportamiento:

El PHB Expedited Forwarding (tratamiento acelerado), definido en el RFC 2598


y despus en 3246, ofrece un ancho de banda garantizado, con una tasa de prdida,
retraso y fluctuacin bajas, similar a un servicio de reserva de recursos (en resumen,
un circuito!). Este PHB se destina a las aplicaciones en tiempo real de tipo
telefona sobre IP. El DSCP toma el valor 46.
El grupo PHB Assured Forwarding (enrutamiento asegurado), definido en el RFC
2597, ofrece cuatro clases de servicio y tres niveles de prioridad (precedencia),
que permiten componer doce PHB diferentes. De esta manera, un proveedor de
acceso puede proporcionar diferentes niveles de servicio definidos por el ancho de
banda asignado, as como el volumen de las colas de espera. Los paquetes que se
ajustan al grupo PHB AF, se asignan a una o varias clases por el cliente o el
proveedor de acceso, segn el contrato de prestacin de servicios firmado. Dentro
de una clase, el paquete se marca de nuevo con una prioridad entre tres, que se
ajusta en caso de congestin en la clase en cuestin, arbitrando la eliminacin de
paquetes.

La siguiente tabla agrupa los valores DSCP recomendados del grupo PHB AF:

La figura siguiente ilustra un ejemplo de uso de los PHBs AF para el despliegue de una
oferta Triple Play sobre ADSL:

Observe que los valores DSCP elegidos no interfieren ni con el antiguo valor de prioridad
000 del campo TOS (Best effort), ni con los antiguos valores de prioridad 11x
correspondientes a la gestin de red. Esto permite que los antiguos routeres TOS-capable
todava presentes en la red, continen funcionando.
El campo ECN (Explicit Congestion Notification), slo apareci en el byte TOS durante su
ltima revisin, propuesta por el RFC3168. La idea es avisar a un emisor de que su emisin
en curso, contribuye a la formacin de una congestin, antes de que se produzca el rechazo
de los paquetes. Adems, se advierte al emisor con la ayuda de banderas situadas en el
acuse de recibo que normalmente debe recibir. No hay creacin de flujo adicional para
alertar a este emisor. De hecho, lo peor sera crear un dispositivo que ayudara a transformar
el riesgo de congestin en congestin efectiva.
Un router mide el riesgo de congestin llenando sus colas de espera. Cuando un router que
utiliza ECN quiere evitar una congestin (la carga media excede un umbral), marca los
paquetes que estn ECN-capable es decir, los paquetes que tienen una etiqueta que
certifica que el emisor entender el marcado. El RFC3168 proporciona la tabla siguiente:
ECN
00

Descripcin
No ECT (ECN Capable Transport), paquete
no ECN

ECN
Descripcin
01 ECT(1): paquete ECN todava sin marcar
ECT(0): paquete ECN todava sin marcar
10
normalmente aprovechado por TCP
CE (Congestion Experienced), paquete
11
ECN marcado
Es complicado ir ms all en la descripcin de este mecanismo, ya que sera necesario tener
slidos conocimientos sobre el protocolo de transporte TCP y abordar algunas nociones
referentes a las estrategias posibles de gestin de la cola de espera.

d. Campo Total Length


Tamao del paquete IP, encabezado + datos, expresado en bytes. El campo est expresado
en 16 bits, la longitud mxima se establece en 65535 bytes, pero es probable que ningn
host ni ninguna red sea capaz de tratar semejantes datagramas. El RFC 791 precisa y el
RFC 1122 lo recuerda, que todo host debe poder aceptar los datagramas para los que la
longitud alcance 576 bytes, ya sean datagramas completos o fraccionados. Por otro lado, un
host no debera emitir un datagrama de longitud superior a 576 bytes, excepto si tiene la
seguridad de que el host remoto puede aceptarlo. Aqu tocamos un punto delicado, al que se
le podra dedicar un captulo completo. Puede encontrarse ms informacin en el estudio
del protocolo de transporte TCP.

e. Campo Identification
Cuando, durante el envo, un proceso IP se ve obligado a fragmentar un paquete para tener
en cuenta el MTU del siguiente salto, el proceso IP destinatario final, deber acometer la
tarea adicional que consiste en reasociar los diferentes fragmentos para reconstruir el
paquete inicial. En este punto se ayuda del campo Identification (un tag), cuyo valor se
genera aleatoriamente en el paquete inicial y despus se copia en cada uno de sus
fragmentos.

f. Campo Banderas
El bit ms significativo no se utiliza y permanece a cero. Los otros dos bits intervienen en
el proceso de fragmentacin:

Bit DF (Dont Fragment): situado a 1, indica que el datagrama no se debe


fragmentar. Un router que no tenga otra opcin, destruir el paquete generando un
mensaje ICMP de informacin de destino inaccesible;
Bit MF (More Fragment): situado a 1, indica que el datagrama slo es una parte del
datagrama inicial. Situado a 0 con un valor del campo Fragment offset diferente de
0, indica que el datagrama es la ltima parte del datagrama inicial.

g. Campo Fragment Offset ( campo clave)


En 13 bits, permite volver a ensamblar un paquete fragmentado, proporcionando la posicin
en el datagrama inicial. Fuera de la cabecera, la posicin expresada en bytes es igual a 8
veces el valor contenido en el campo Fragment Offset (Desplazamiento).
Ejemplo: enviar 1400 bytes de datos en una conexin de MTU 620.
El datagrama inicial se ha emitido en una red LAN de MTU 1500. Suponiendo que el
encabezado IP no tenga opciones, cada datagrama emitido en la conexin MTU 620 puede
tener 620 - 20 = 600 bytes de datos.

el primer datagrama lleva el primer fragmento de 600 bytes, le quedan 800;


el segundo datagrama lleva el segundo fragmento de 600 bytes, le quedan 200;
el tercer datagrama lleva el ltimo fragmento de 200 bytes.

Los valores correspondientes del campo Fragment Offset y del bit MF son:
Nmero de fragmento
1
2
3

Datos transportados
600
600
200

Fragment Offset
0
600/8 = 75
75 + 75 = 150

Bit MF
1
1
0

Podemos identificar un datagrama no fragmentado cuando, tanto el bit MF como el valor de


desplazamiento, son iguales a 0.

h. Campo TTL ( campo clave)


En 8 bits, vida til del datagrama en la red, expresado en segundos. Cada router por el que
transita el paquete, decrementa la vida til en al menos uno, sea cual sea el tiempo inferior
a uno transcurrido en el router. En la prctica, este campo se considera como el nmero de
saltos mximo que limita el alcance del paquete, pero sobre todo, que permite eliminar un
datagrama que vaga por la red sin alcanzar nunca su destino (bucle de enrutamiento).

i. Campo Protocol ( campo clave)


En 8 bits, el campo Protocol contiene el N-SAP de capa 3, es decir, la informacin que
permite al proceso IP de destino resituar la carga til al protocolo de capa 4 adecuado. Este
mecanismo se llama demultiplexacin de protocolo:

Los nmeros asignados son bien conocidos y por lo tanto gestionados por la autoridad
IANA. La lista se encuentra en el sitio web: http://www.iana.org/assignments/protocolnumbers/protocol-numbers.xhtml

Es imprescindible conocer algunos valores, como ICMP 1, TCP 6 o UDP 17.

j. Campo Header checksum


La suma de control del encabezado, expresada en 16 bits, permite garantizar la integridad
del encabezado del datagrama IP. Un router que recibe un datagrama calcula esta suma y
despus la compara con la suma recibida. Si los valores son diferentes, el paquete se
destruye y el router genera un mensaje ICMP. Si los valores son idnticos, el router
decrementa el valor TTL, lo que le obliga a recalcular una suma de control que sustituye a
la recibida, antes de enviar el paquete al router siguiente. El procedimiento de clculo es el
siguiente:

1) Poner checksum a 0.
2) Calcular la suma de las palabras de 16 bits que componen el encabezado.
3) Aadir resta1 a suma1.
4) Aadir resta2 a suma2.
5) Complementar a 1 suma3 obtenemos el valor buscado.

k. Campo Address Source ( campo clave)


La direccin Source identifica al emisor del datagrama y los routeres no la modifican. Por
lo tanto, permanece inalterable durante todo el proceso de enrutamiento del paquete.

l. Campo Address Destination ( campo clave)


La direccin Destination identifica el destinatario final del datagrama y los routeres no la
modifican. Por lo tanto, permanece inalterable durante todo el proceso de enrutamiento del
paquete (excepto, de nuevo, si hay traduccin de direcciones de red).

m. Campo Options
La presencia de opciones se indica por medio de un valor del campo IHL superior a cinco.
Las opciones se destinan normalmente a realizar pruebas durante las fases de optimizacin.
La organizacin de las opciones recuerda a la de la zona del proveedor de BOOTP: cada
opcin presente tiene un cdigo de opcin en un byte, seguido de un campo longitud y de
los datos propios de la opcin:

Para poner un ejemplo, la opcin Registro de ruta tiene una lista vaca de direcciones IP en
el momento de su emisin por el origen. Despus, cada router que hace avanzar al
datagrama, aade su direccin IP a la lista. El campo Puntero le permite determinar la
siguiente ubicacin libre en el campo Datos de la opcin.

n. Campo Padding (Atasco)


El campo IHL expresa la longitud del encabezado en unidades de 32 bits y el campo Atasco
permite conseguir una longitud mltiplo de 32 bits, cuando esto no es posible de manera
natural. Cuando, por ejemplo, no hay opciones, el campo Atasco no es necesario y por
tanto, la longitud del encabezado se fija en 5 x 4 bytes.

Você também pode gostar