FUNDAMENTOS DEL TCP/IP
ACERCA DEL
TCP/IP
El
TCP/IP es una colección de protocolos estándar de la industria diseñada para
intercomunicar grandes redes (WANs = Wide Area
Networks).
Las
siglas TCP/IP provienen de Transmission Control Protocol / Internet
Protocol.
Vamos
a intentar dar en esta parte, unos conceptos sobre TPC/IP, su terminología y
explicar como la Internet Society crea el estándar de
Internet.
HISTORIA DEL TCP/IP
El
TCP/IP fue originado con los
experimentos de intercambio de paquetes dirigido por el U.S. Department of
Defense Advanced Research Projects Agency (DARPA) durante la década de 1960
a 1970.
Hay
varios hitos importantes en la historia del TCP/IP:
1970:
Los ordenadores de la Advanced Research Agency Network (ARPANET)
comienzan a utilizar el NCP (Network Control
Protocol).
1972:
La primera especificación Telnet. “Ad hoc Telnet Protocol” se define como
una RFC, la 318.
1973:
RFC 454. Se introduce el FTP (File Transport
Protocol)
1974:
El TCP (Transmission Control Program) se especifica
detalladamente.
1981:
El estándar IP se publica en la RFC 791
1982:
La ‘Defense Communications Agency’ (DCA) y ARPA establecen a la
‘Transmision Control Protcolol (TCP) y al Internet Protocol (IP)
como la colección de protocolos TCP/IP.
1983:
ARPANET cambia de NCP a TCP/IP
1984:
Se define el concepto de DNS (Domanin Name System)
EL PROCESO DE ESTANDARIZACION DE INTERNET
Surge
un grupo internacional de voluntarios llamado Internet Society para
administrar la colección de protocolos TCP/IP. Los estándares para el TCP/IP son
publicados en una serie de documentos llamados Request For Comments, o
simplemente RFCs. Debemos tener presente que Internet nació como libre y
sigue como libre. Por tanto esta no es una organización “propietaria” de
Internet o de sus tecnologías. Únicamente son responsables de su
dirección.
ISOC
Internet
SOCiety
(ISOC) fue creada en 1992 como una organización global responsable de las
tecnologías de trabajo en Internet y las aplicaciones de Internet. Su principal
propósito es animar al desarrollo y la disponibilidad de
Internet.
IAB
La
IAB (Internet Architecture Board) es el grupo
técnico de la ISOC responsable de las opciones estándar de Internet, publicar las RFCs y vigilar
los procesos estándar de Internet.
El IAF
dirige la IETF (Internet Engineering Task Force), IANA (Internet
Assiged Numbers Authority) y la IRTF (Internet Research Task Force).
La
IETF desarrolla los estándares y protocolos Internet, y vigila y desarrolla
soluciones a problemas técnicos alrededor de Internet. La IANA vigila y coordina
la asignación de un identificador único en Internet: las direcciones IP. El
grupo IRTF es el responsable de la coordinación de todos los proyectos
relacionados con el TCP/IP.
RFCs
Los
estándares del TCP/IP se publican en una serie de documentos llamados Request
For Comment (RFCs). Los RFCs describen todo el trabajo interno en Internet.
El estándar TCP/IP es siempre publicado como una RFC, pero no todas las RFCs
especifican estándares.
El
TCP/IP estándar, no ha sido desarrollado por un comité. Ha sido desarrollado
“por consenso”. Cualquier miembro de la Internet Society puede publicar
un documento como una SFC. El documento es revisado por un grupo de expertos y
se le asigna una clasificación. Hay cinco clases de clasificaciones en las
RFCs:
Si
un documento comienza a ser considerado como un estándar, comienza a pasar por
los diferentes estados de desarrollo, prueba y aceptación. Durante este proceso,
estos procesos son formalmente llamados ‘maturity levels’ (niveles de
maduración). Hay tres niveles de maduración en los estándares de
Internet:
Cuando
se publica un documento, se le asigna un numero de RFC. Este numero original,
nunca va a cambiar. Si esta RFC requiera cambios, se publica una nueva RFC con
un nuevo numero.
La
IAB publica el ‘IAB Official Protocol Standard’
trimestralmente.
VISION GENERAL DE LA ARQUITECTURA TCP/IP
EL
PROTOCOLO TPC/IP
EL MODELO DE 4 CAPAS
Aunque este modelo es general en todas las implementaciones del TCP/IP, a lo largo del presente documento, vamos a ceñirnos a su implementación en Microsoft Windows.
Aplicaciones Windows
Sockets Aplicaciones
NetBIOS
Aplicación
Sockets NetBIOS NetBios
sobre
TCP/IP
TDI
UDP TCP
Transporte
IGMP ICMP IP
Internet
ARP
Tecnologías
LAN: Ethernet,
Token Ring,
FDDI Tecnologías
WAN: Lineas
Serie, Frame Relay,
ATM
Red
Capa
de Red:
La base de este modelo de capas, es la capa de interface de red. Esta
capa es la responsable de enviar y recibir frames (estructuras o marcos.
Pero prefiero a partir de ahora dejar el termino inglés, ya que es ampliamente
aceptado en la terminología informática), los cuales son los paquetes de
información que viajan en una red cono una ‘unidad simple’. La capa de red,
envía frames a la red, y recupera frames de la
red.
Capa
de Internet:
Este protocolo encapsula paquetes en datagramas internet (no es tampoco
la palabra datagrama una palabra castellana, pero es también aceptada en
la terminología informática como ‘paquete de datos’) y además esta capa ejecuta
todos los algoritmos de enrutamiento (routing) de paquetes. Los
cuatro protocolos Internet son: Internet Protocol (IP), Address
Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) y
Internet Group Management Protocol (IGMP).
- IP
es el responsable del envío y enrutamiento de paquetes entre maquinas y
redes.
- ARP
obtiene las direcciones de hardware de las maquinas situadas en la misma red
física. Recordemos que la dirección física de cada tarjeta de red es única en
el mundo. Dicha dirección “física” ha sido implementada vía hardware por el
fabricante de la tarjeta de red, y dicho fabricante, lo selecciona de un rango
de direcciones único asignado a él y garantiza la unicidad de dicha tarjeta.
Este caso es el más corriente y es el de las tarjetas de Red Ethernet. Existe
para otras topologías de red, igualmente una asignación única hardware de
reconocimiento de la tarjeta.
- ICMP
envía mensajes e informa de errores en el envío de paquetes.
- IGMP
se utiliza para la comunicación entre routers (enrutadores de
Internet).
Capa de Transporte: La capa de transporte,
nos da el nivel de “sesión” en la comunicación. Los dos protocolos posibles de
transportes son TCP (Transmission Control Protocol) y UDP (User
Datagram Protocol). Se puede utilizar uno u otro protocolo dependiendo del
método preferido de envío de datos.
El
TCP nos da un tipo de conectividad “orientada a conexión”. Típicamente se
utiliza para transferencias de largas cantidades de datos de una sola vez. Se
utiliza también en aplicaciones que requieren un “reconocimiento” o validación
(ACK : acknowledgment) de los datos recibidos.
El
UDP proporciona conexión de comunicación y no garantiza la entrega de paquetes.
Las aplicaciones que utilicen UDP normalmente envían pequeñas cantidades de
datos de una sola vez. La aplicación que lo utilice, es la responsable en este
caso de la integridad de los paquetes y debe establecer sus propios mecanismos
para pedir repetición de mensaje, seguimiento, etc, no existiendo ni garantía de
entrega ni garantía del orden de entrega en la maquina
destino.
Capa
de Aplicación:
En la cima de este modelo, está la capa de aplicación. Esta es la capa que las
aplicaciones utilizan para acceder a la red. Existen muchas utilidades y
servicios en la capa de aplicación, por ejemplo: FTP, Telnet, SNMP y
DNS.
Otras
implementaciones del TCP, por ejemplo ‘Unix’ estándar, nos da únicamente en la
capa de aplicación los “sockets”. Microsoft Windows nos da dos interfaces
para las aplicaciones de red que usan los servicios del TCP/IP. El primero,
llamado ‘Windows Sockets’ nos da una interface de programación estándar
(API) bajo Microsoft Windows para protocolos de transporte como el TCP/IP y el
IPX.
La
segunda interface para las aplicaciones de red es el NetBIOS. Esta
interface nos da un estándar para el soporte de nombre NetBIOS y
servicios de mensajes, usados en TCP/IP y el NetBeui.
TECNOLOGÍAS DE
INTERFACE DE RED
El
IP utiliza la especificación de dispositivos de red (NDIS: Network Device
Interface specification) para enviar frames a capa de Red. IP soporta
tecnologías LAN y WAN.
Las
tecnologías LAN soportadas por el TCP/IP incluyen Ethernet (Ethenet II y 802.3)
Token Ring, ArcNet y tecnologías MAN (Metropolitan Area Network) como la
interface de datos en fibra optica (FDDI: Fiber Distributed Data
Interface).
Usando
TCP/IP en un entorno WAN puede requerir los servicios de RAS activados, o
incluso hardware adicional. Las dos máximas categorías de las tecnologías WAN
soportadas son: líneas serie y packets-switched. Las líneas serie
incluyen las llamada telefónicas analógicas. Packets-switched incluyen
X.25, frame relay, y comunicaciones en modo de transferencia asíncrona
(ATM: Asynchronous Transfer Mode).
Protocolos sobre líneas serie
El
TCP/IP es enviado en las lineas serie encapsulado con los protocolos SLIP
(Serial Line Internet Protocol) o bien bajo PPP (Point-to-Point
Protocol). Este ultimo caso es el que normalmente utilizamos al utilizar
cualquier módem para conectarnos a Internet.
SLIP
es un estándar de la industria desarrollado a mediados de 1980 para soportar
TCP/IP en redes de baja velocidad. Utilizando el RAS de Windows NT (o Windows
2000) las maquinas ejecutando Windows, pueden usar TCP/IP y SLIP para
comunicarse a maquinas remotas.
- Debemos
recordar que Windows NT (o Windows 2000) soportan la funcionalidad de cliente
SLIP, no la funcionalidad de servidor SLIP.
PPP
fue diseñado como una mejora de la funcionalidad SLIP original. El PPP es un
protocolo de enlace de datos que nos da un método estándar de enviar paquetes a
la red en un enlace punto a punto. Debido a que PPP nos da mayor seguridad,
configuración, y detección de errores que SLIP, es el protocolo recomendado para
comunicaciones en líneas serie.
La
transmisión de IP sobre líneas serie está descrita en la RFC 1055. El PPP está
definido en las RFCs 1547 y 1661.
ARP
Cualquier maquina debe conocer ‘siempre’ la dirección hardware (física) de otra maquina para poder comunicarse vía red. La resolución de direcciones es el proceso de convertir direccione IP en direcciones hardware. El ARP (Address Resolution Protocol), es parte de las capas del TCP/IP, obtiene direcciones hardware de las maquinas localizadas en la misma red física.
Vamos a introducir aquí un termino inglés ‘broadcast’ o ‘broadcasting’ que voy a dejar de dicha manera debido a su uso cotidiano en el lenguaje de redes y debido a que su traducción al castellano no tiene todo el sentido que dicha palabra expresa. Su traducción litera es: radiodifusión. Realmente lo que indica es que un mensaje es enviado a la red a todas las maquinas y lo recogerá la maquina que se de por ‘enterada’.
ARP es el responsable de obtener las direcciones hardware de las maquinas TCP/IP en redes basadas en ‘broadcasting’. ARP usa un broadcast local de la dirección IP de destino para localizar la dirección hardware de la maquina destino o del gateway.
(por gateway debemos entender un router –enrutador- o cualquier maquina que nos de salida des nuestra red local o nuestro segmento de red local, a otro segmentos locales de red o bien a otras redes como por ejemplo Internet).
Una vez que el ARP obtiene la dirección hardware, ambos, la dirección IP y la dirección hardware son almacenadas en una entrada en la caché ARP. ARP siempre chequea la caché ARP para una dirección IP antes de iniciar una petición mediante broadcast a la red.
La resolución de direccionamiento inverso es el proceso de convertir una dirección hardware en una dirección IP. No todas las implementaciones del TCP/IP soportan esto. Por ejemplo, Microsoft Windows no soporta resolución inversa de direcciones.
El
ARP está definido en la RFC 826.
Resolviendo una dirección IP local.
Antes de que la comunicación entre dos maquinas pueda ocurrir, la dirección IP de cada maquina debe ser resuelta como dirección física (hardware). El proceso de resolución de direcciones incluye una petición ARP y una respuesta ARP. Vamos a intentar explicarlo en el siguiente ejemplo:
1) Una
petición ARP se inicia en cualquier momento en que una maquina intenta
comunicarse con otra. Cuando el IP determina que la dirección IP es en la red
local, la maquina origen de la petición chequea su propia caché ARP para
ver si allí tiene la dirección hardware de la maquina
destino.
2) Si
no encuentra la dirección en su propia caché, ARP envía una petición con
una pregunta del tipo “Quien tenga esta dirección IP, que me envíe su dirección
hardware”. Tanto la dirección IP del origen como su dirección hardware son
incluidas en el mensaje de petición. El mensaje de petición es enviado mediante
broadcast a todas las maquinas en la red local.
3) Cada
maquina en la red local recibe el mensaje enviado por broadcast y
comprueba si se está solicitando su propia dirección IP. Si el mensaje no es
para esa maquina, ignora dicha petición.
4) Al
final, la maquina de destino comprueba que la petición le coincide con su propia
dirección IP y envía una respuesta ARP directamente a la maquina peticionaria ya
que en el propio mensaje va la dirección hardware del peticionario. Este además
actualiza su propia caché ARP con la direccio IP / dirección hardware de
la maquina peticionaria. La comunicación se establecerá cuando la maquina origen
reciba la respuesta.
Caché
ARP 10.230.1.10
071001A… Caché
ARP 10.230.1.1
07A00B….
1)
2)
3)
Dirección HW: 071002B....
4)
Dirección IP: 10.230.1.10
Dirección IP: 10.230.1.3
Dirección HW: 071001A....
Dirección HW: 071002B...
Resolviendo una dirección IP
remota.
ARP
también nos permite que dos maquinas de diferentes redes se comuniquen. En esta
situación la petición ARP mediante broadcasting es para el gateway
por defecto y no para la dirección IP de la maquina destino. Es decir la
petición broadcast es para determinar el router que puede enviar
los datagramas a la maquina destino en la red. Veamos el siguiente
ejemplo:
1) Cuando
iniciamos la petición, la dirección de destino IP se identifica como
perteneciente a una red ‘remota’. La maquina origen chequea su tabla de ‘rutas’
para encontrar un camino a la maquina o a la red destino. Si no encuentra
coincidencia, la maquina origen determina la dirección del gateway por
defecto. Chequea igualmente su caché ARP para la dirección IP / dirección
hardware del gateway por defecto en este caso.
2) Si
no encuentra coincidencia para el gateway, entonces se envía una petición
ARP mediante broadcast para la dirección del gateway en vez de
para la dirección de la maquina destino. El router responderá a ma
maquina origen con ‘su’ propia dirección hardware. La maquina origen, entonces
envía los paquetes de datos al gateway para que este a su vez y siguiendo
un proceso similar, los reenvíe a la maquina destino.
3) En
el router, la dirección IP destino también es investigada para ver si es
local o remota.Si es local, el router usa la técnica ARP (primero en la
caché y luego por broadcast) para obtener su dirección hardware.
Si es una dirección remota, el router chequea su tabla de rutas para
encontrar un gateway para esa dirección y entonces usa ARP (caché
o boradcast) para obtener la dirección hardware del siguiente
gateway hasta el destino. El paquete se envia a la siguiente maquina de
detino.
4) Después
de que la maquina destino reciba la petición, esta responde con un mensaje de
respuesta ICMP. Debido a que la maquina origen está en una red remota, la tabla
de rutas local se chequea para encontrar un gateway para la dirección de
la maquina origen. Cuando encuentra un gateway, ARP obtiene su dirección
hardware.
5) Si
la dirección hardware del gateway no está en la caché ARP una
petición broadcast obtendrá esta. Una vez obtenida su dirección hardware,
la respuesta ICMP es enviada al router que encaminará estos datos a la
maquina origen.
Bien.
En este caso el grafico de envió y peticiones es algo más complicado que el
anterior. Se propone como ejercicio y espero que no tenga mayores complicaciones
que la de hacer intervenir una maquina más: un
router.
La caché
ARP
Para
intentar minimizar el numero de broadcast a la red, el ARP mantiene
siempre las direcciones de hardware conocidas y que fueron resueltas por primera
vez mediante broadcasting.
Cada
entrada en la caché de la ARP tiene un tiempo potencial de vida de 10
minutos. En cada entrada en la ARP, se guarda los datos de fecha / hora
(timestamp). Si esta entrada no es usada en los dos primeros minutos, se
borra de la caché. Si se utiliza será borrada después de los 10 primeros
minutos. Si la caché del ARP alcanza su capacidad máxima antes de que las
entradas anotadas en ella expiren, la entrada más antigua será borrada y la
nueva será añadida en su lugar.
En
algunas implementaciones del TCP/IP cuando una entrada de la caché del
ARP es utilizada, se le añaden otros 10 minutos de vida. En Microsoft Windows no
esta implementada esta característica.
ICMP e IGMP
Mientras
que el IP es el protocolo para el envío, ICMP (Internet Control Message
Protocol) nos informa de errores y mensajes de control en nombre del IP. IP
usa IGMP (Internet Group Management Protocol) para informar a los
routers que los hosts (maquinas) de un grupo especifico están
disponibles en una red.
ICMP
ICMP
no espera convertir al IP en un protocolo seguro y fiable. Meramente comunica
errores e informa de condiciones especificas. Los mensajes ICMP son enviados
como datagramas IP y son por tanto inseguros en si
mismos.
Por
ejemplo, si una maquina está enviando datagramas a otra maquina a una
velocidad que está saturando routers o enlaces entre ellos, el
router puede enviar un mensaje ICMP del tipo ‘Source Quench’. Este
mensaje le informa al host de una petición de disminuir su velocidad de
trasmisión.
Dependiendo
de la implementación del TCP/IP, este mensaje ICMP puede ser o no enviado al
origen. Existen implementaciones que en vez de enviar este mensaje, o bien si no
se ha respondido a la petición de este mensaje, simplemente ‘pierde’ o
‘descarta’ los datagramas que no puede procesar en el envío sin
preocuparse más de ellos.
- Recordemos
que el TCP/IP sigue la filosofía de la ‘patata caliente’ con los
datagramas IP. Si puede enviarlos rápidamente, los envía. Sino
simplemente la ‘patata’ se tira. Está caliente y quema por tanto no podemos
guardárnosla.
ICMP
está definido en la RFC 792
IGMP
Es
el equivalente a los mensajes ICMP pero entre los routers en vez de entre
maquinas en las que interviene un host en alguno de sus
extremos.
Los
mensajes IGMP son enviados como datagramas IP y son por tanto inseguros
en si mismos.
IGMP
está definido en la RFC 1112
IP
IP
es el protocolo primario de conexión responsable del envío y enrutamiento de
paquetes entre maquinas (hosts).
IP
no establece una sesión antes de intercambiar datos. IP no es fiable debido a
que trabaja sin garantía de entrega. A lo largo del camino, un paquete puede
perderse, cambiarse de secuencia, duplicarse, retrasarse, o incluso
trocearse.
IP
no requiere una comunicación ACK (axknowledgment) cuando se reciben los
datos. El emisor o el receptor no es informado cuando un paquete se pierde o se
envia fuera de secuencia. El ACK de los paquetes es responsabilidad de una capa
de más alto nivel de transporte como por ejemplo el TCP.
Si
el IP identifica una dirección de destino como una dirección ‘local’, el IP
envia el paquete directamente a la maquina. Si el destino es identificado como
un destino ‘remoto’, el IP chequea sus tablas de rutas. Si encuentra una ruta,
el IP envía el paquete utilizando esa ruta. Si no encuentra una ruta, el IP
envía el paquete al gateway por defecto (tan bien llamado
router).
Al datagrama se le añaden los campos
descritos a continuación a su cabecera cuando se pasa un paquete a la capa
de transporte.
IP
en el router.
Cuando
un router recibe un paquete, el paquete es pasado a la capa IP la cual
realiza lo siguiente:
1) Decrementa
el campo TTL (Time To Live) al menos en 1. Puede ser disminuido en una
cantidad mayor si el router estuviese congestionado. Si el TLL alcanza el
valor de cero, el paquete será descartado.
2) El
IP puede fragmentar el paquete en paquetes más pequeños si el paquete fuese
demasiado largo para las líneas de salida del
router.
3) Si
el paquete es fragmentando, el IP crea una nueva cabecera para cada nuevo
paquete la cual incluye:
- Un
flag (indicador) de que le siguen nuevos
fragmentos.
- Un
numero de fragmento (Fragment ID) para identificar todos los
fragmentos que continúan.
- Un
desplazamiento (Fragment Offset) para permitir que la maquina que lo
va a recibir sea capaz de reensamblar el paquete.
4) El
IP calcula los nuevos cheksum.
5) El
IP obtiene la dirección hardware del siguiente
router.
6) Envía
el paquete.
En
el siguiente host, el paquete subirá en el stack (pila o capa de
protocolos) hasta el TCP o el UDP. Este proceso se repite en cada router
hasta que el paquete encuentra su destino final. Cuando el paquete llega a su
destino final el IP ensamblará las piezas tal y como estaba el paquete
original.
Estructura
del paquete IP
Los campos del paquete IP en la versión 4 del TCP/IP (versión actual) son los siguientes:
|
Campo |
Función |
|
Versión |
Son
utilizados 4 bits para indicar la versión dl IP. La versión actual es la
versión 4. La siguiente versión del IP va a ser la versión
6. |
|
Longitud
de la cabecera |
Se
utilizan 4 bits que indican el numero de palabras de 32-bits en la
cabecera IP. La cabecera IP tiene un mínimo de 20
bytes. |
|
Tipo
de servicio |
Se
utilizan 8 bits para indicar la calidad del servicio esperado por este
datagrama para entrega a través de los routers en la red IP.
Especifican procedencia, demora, y tipo de
entrega. |
|
Longitud
total |
16
bits son utilizados para indicar la longitud ‘total’ incluida cabecera del
datagrama IP. |
|
Identificación |
16
bits son utilizados para identificar este paquete. Si el paquete fuese
fragmentado, todos los segmentos que tuviesen esta misma identificación
serán usados para
reensamblarlos en la maquina destino. |
|
Flags
de fragmentación |
3
bits son reservados como indicadores del proceso de fragmentación. Sin
embargo únicamente 2 bits están definidos para el proceso en curso. Uno de
ellos es para indicar cuando el datagrama puede ser fragmentado y
el otro para indicar que hay más fragmento que lo
siguen. |
|
Offset
del fragmento. |
13
bits se utilizan como un contador del desplazamiento para indicar la
posición del fragmento relativo al paquete IP original. Si el paquete no
estuviese fragmentado este campo contendrá un
cero. |
|
Tiempo
de Vida (TTL) |
8
bits se utilizan para indicar la cantidad de vida o de ‘saltos’ que un
paquete IP puede realizar antes de ser
descartado. |
|
Protocolo |
8
bits se utilizan como un identificador del
protocolo. |
|
Checksum
de la cabecera |
16
bits son usados como checksum de la cabecera IP unicamente. El
cuerpo del mensaje IP no está incluido y deberá ser incluido en él, su
propio checksum para evitar errores. |
|
Dirección
Origen |
32
bits que almacenan la dirección IP del origen. |
|
Dirección
destino |
32
bits que almacenan la dirección IP del
destino. |
|
Opciones
y relleno |
Un
múltiplo de 32 bits es utilizado para almacenar las opciones IP. Si las
opciones IP no utilizan los 32 bits, se rellenan con bits adicionales a
ceros para que la longitud de la cabecera IP sea un numero entero de
palabras de 32 bits. |