manual tcp ip

Manual Tecnico y Práctico Protocolo TCP/IPTrucoswindowsnet

Protocolo TCP/IP

Protocolos de RedUna red es una configuración de computadora que intercambia información. Pueden

proceder de una variedad de fabricantes y es probable que tenga diferencias tanto en hardware como en software, para posibilitar la comunicación entre estas es necesario un conjunto de reglas formales para su interacción. A estas reglas se les denominan protocolos.

Un protocolo es un conjunto de reglas establecidas entre dos dispositivos para permitir la comunicación entre ambos.

1


Protocolo IP

El protocolo IP es el software que implementa el mecanismo de entrega de paquetes sin conexión y no confiable (técnica del mejor esfuerzo).

El protocolo IP cubre tres aspectos importantes:1. Define la unidad básica para la transferencia de datos en una interred,

especificando el formato exacto de un Datagrama IP.2. Realiza las funciones de enrutamiento.3. Define las reglas para que los Host y Routers procesen paquetes, los

descarten o generen mensajes de error.

El Datagrama IP

El esquema de envío de IP es similar al que se emplea en la capa Acceso a red. En esta ultima se envían Tramas formadas por un Encabezado y los Datos. En el Encabezado se incluye la dirección física del origen y del destino.

En el caso de IP se envían Datagramas, estos también incluyen un Encabezado y Datos, pero las direcciones empleadas son Direcciones IP.

Encabezado Datos

Formato del Datagrama IP

Los Datagramas IP están formados por Palabras de 32 bits. Cada Datagrama tiene un mínimo (y tamaño más frecuente) de cinco palabras y un máximo de quince.

Ver Hlen TOS Longitud TotalIdentificación Flags Desp. De Fragmento

TTL Protocolo ChecksumDirección IP de la FuenteDirección IP del Destino

Opciones IP (Opcional) Relleno

DATOS

2


• Ver: Versión de IP que se emplea para construir el Datagrama. Se requiere para que quien lo reciba lo interprete correctamente. La actual versión IP es la 4.

• Hlen: Tamaño de la cabecera en palabras.• TOS: Tipo de servicio. La gran mayoría de los Host y Routers ignoran este

campo. Su estructura es:

Prioridad D T R Sin Uso

La prioridad (0 = Normal, 7 = Control de red) permite implementar algoritmos de control de congestión más eficientes. Los tipos D, T y R solicitan un tipo de transporte dado: D = Procesamiento con retardos cortos, T = Alto Desempeño y R = Alta confiabilidad. Nótese que estos bits son solo “sugerencias”, no es obligatorio para la red cumplirlo.

• Longitud Total: Mide en bytes la longitud de doto el Datagrama. Permite calcular el tamaño del campo de datos: Datos = Longitud Total – 4 * Hlen.

Antes de continuar con la segunda palabra del Datagrama IP, hace falta introducir conceptos relacionados con la fragmentación.

Fragmentación

En primer lugar, De qué tamaño es un Datagrama?. El tamaño para un Datagrama debe ser tal que permita la encapsulación, esto es, enviar un Datagrama completo en una trama física. El problema está en que el Datagrama debe transitar por diferentes redes físicas, con diferentes tecnologías y diferentes capacidades de transferencia. A la capacidad máxima de transferencia de datos de una red física se le llama MTU (el MTU de ethernet es 1500 bytes por trama, la de FDDI es 4497 bytes por trama). Cuando un Datagrama pasa de una red a otra con un MTU menor a su tamaño es necesaria la fragmentación. A las diferentes partes de un Datagrama se les llama fragmento. Al proceso de reconstrucción del Datagrama a partir de sus fragmentos se le llama Reensamblado de fragmentos.

El control de la fragmentación de un Datagrama IP se realiza con los campos de la segunda palabra de su cabecera:

• Identificación: Numero de 16 bits que identifica al Datagrama, que permite implementar números de secuencias y que permite reconocer los diferentes fragmentos de un mismo Datagrama, pues todos ellos comparten este numero.

3


• Banderas: Un campo de tres bits donde el primero está reservado. El segundo, llamado bit de No Fragmentación significa: 0 = Puede fragmentarse el Datagrama o 1 = No puede fragmentarse el Datagrama. El tercer bit es llamado Más – Fragmentos y significa: 0 = Unico fragmento o Ultimo fragmento, 1 = aun hay más fragmentos. Cuando hay un 0 en más – fragmentos, debe evaluarse el campo desp. De Fragmento: si este es cero, el Datagrama no esta fragmentado, si es diferente de cero, el Datagrama es un ultimo fragmento.

• Desp. De Fragmento: A un trozo de datos se le llama Bloque de Fragmento. Este campo indica el tamaño del desplazamiento en bloques de fragmento con respecto al Datagrama original, empezando por el cero.

Para finalizar con el tema de fragmentación, hay que mencionar el Plazo de Reensamblado, que es un time out que el Host destino establece como máximo para esperar por todos los fragmentos de un Datagrama. Si se vence y aun no llegan TODOS, entonces se descartan los que ya han llegado y se solicita el reenvío del Datagrama completo.

Formato del Datagrama IP (Cont.)

• TTL: Tiempo de Vida del Datagrama, especifica el numero de segundos que se permite al Datagrama circular por la red antes de ser descartado.

• Protocolo: Especifica que protocolo de alto nivel se empleó para construir el mensaje transportado en el campo datos de Datagrama IP. Algunos valores posibles son: 1 = ICMP, 6 = TCP, 17 = UDP, 88 = IGRP (Protocolo de Enrutamiento de Pasarela Interior de CISCO).

• Checksum: Es un campo de 16 bits que se calcula haciendo el complemento a uno de cada palabra de 16 bits del encabezado, sumándolas y haciendo su complemento a uno. Esta suma hay que recalcularla en cada nodo intermedio debido a cambios en el TTL o por fragmentación.

• Dirección IP de la Fuente:• Dirección IP del Destino:• Opciones IP: Existen hasta 40 bytes extra en la cabecera del Datagrama IP que pueden llevar una o más opciones. Su uso es bastante raro.

Uso de Ruta Estricta (Camino Obligatorio)

Ruta de Origen Desconectada (Nodos Obligatorios)

Crear registro de Ruta

Marcas de Tiempo

Seguridad Básica del Departamento de Defensa

Seguridad Extendida del Departamento de Defensa

4


Enrutamiento IP

Enrutar es el proceso de selección de un camino para el envío de paquetes. La computadora que hace esto es llamada Router.

En general se puede dividir el enrutamiento en Entrega Directa y Entrega Indirecta. La Entrega Directa es la transmisión de un Datagrama de una maquina a otra dentro de la misma red física. La Entrega Indirecta ocurre cuando el destino no esta en la red local, lo que obliga al Host a enviar el Datagrama a algún Router intermedio. Es necesario el uso de mascaras de subred para saber si el Host destino de un Datagrama esta o no dentro de la misma red física.

Encaminamiento con Salto al Siguiente.

La forma más común de enrutamiento requiere el uso de una Tabla de Enrutamiento IP, presente tanto en los Host como en los Routers. Estas tablas no pueden tener información sobre cada posible destino, de hecho, esto no es deseable. En ves de ello se aprovecha el esquema de direcionamiento IP para ocultar detalles acerca de los Host individuales, además, las tablas no contienen rutas completas, sino solos la dirección del siguiente paso en esa ruta.

En general una tabla de encaminamiento IP tiene pares (Destino, Router), donde destino es la dirección IP de un destino particular y Router la dirección del siguiente Router en el camino hacia destino. Nótese que Router debe ser accesible directamente desde la maquina actual.

Este tipo de encaminamiento trae varias consecuencias, consecuencia directa de su naturaleza estática:

1. Todo trafico hacia una red particular toma el mismo camino, desaprovechando caminos alternativos y el tipo de trafico.

2. Solo el Router con conexión directa al destino sabe si este existe o esta activo.

3. Es necesario que los Routers cooperen para hacer posible la comunicación bidireccional.

Manejo de Datagramas Entrantes.

Cuando un Datagrama llega a un Host, el software de red lo entrega a IP. IP verifica la dirección de destino y si esta concuerda con la de la maquina local, entonces acepta el Datagrama y lo entrega a las capas superiores. De no coincidir la dirección de destino, el Datagrama es descartado.

5


Por otra parte, un Router que reciba un Datagrama compara la dirección de destino con la suya propia. Si coinciden, el Datagrama pasa a las capas superiores, sino, se le aplica el algoritmo de encaminamiento y se reenvía el Datagrama.

Direccionamiento sin Clase

Durante la introducción a TCP/IP (Juan Carlos Guevara), se explicaba como mediante el empleo de Mascaras de subred, se lograba convertir una única red (generalmente una Clase B) en múltiples redes lógicas interconectadas y administradas por la organización propietaria. El problema se presenta cuando el crecimiento explosivo de las redes locales produce el fenómeno ROADS (Running Out of Address Space), que consiste simplemente en el agotamiento del espacio de direcciones útil, causado por la gran demanda de las direcciones Clase B, de las cuales solo hay 16.384, mientras que las Clases C permanecían sin Asignar (pues aunque hay 2.097.152 de ellas, nadie las quiere por ser muy pequeñas).

Para enfrentar este problema se desarrollo el esquema de Direcciones sin Clase, que consiste en asignar a una misma organización un bloque continuo de direcciones de Clase C. De esta manera, una organización que requiera conectar a Internet un numero moderado de Hosts (digamos 3.800) puede recibir un bloque de 16 redes continuas de Clase C (por ejemplo, de la red Clase C 199.40.72.0 a la 199.40.87.0), con lo cual dispone de 4.096 direcciones IP validas para administrar.

CIDR Enrutamiento Inter – Dominio Sin Clases (Classless Inter – Domain Routing)

El esquema de direcciones sin clase genera el problema de aumentar la información que debe incluirse en las tablas de enrutamiento. En el caso del ejemplo, se tendría que incluir 16 nuevas entradas en cada tabla de enrutamiento de cada Host y Router. CIDR resuelve el problema al incluir en las tablas información acerca del tamaño de los bloques y el numero de bloques, así, en las tablas de enrutamiento IP se tienen pares (Destino, Router), donde destino no es una dirección de Host o Red tradicional, sino que incluye información acerca del numero de redes que incluye el bloque (en nuestro ejemplo, 16) y el tamaño de cada una de esas redes (en el ejemplo, son Clases C, 256 direcciones cada una).

El Direccionamiento sin clase modifica la estructura de una dirección IP, de esta manera:

Prefijo de Red Identificador de Host

6


Así, CIDR debe incluir en las tablas de enrutamiento cual es la primera red que compone el bloque, cuantos bits se emplean como Prefijo de Red y la mascara de subred que se emplea. En nuestro ejemplo, las tablas de enrutamiento IP contendrían esta información:

199.40.72.0/20 255.255.240.0

Refiriéndose a un bloque que se inicia con la red 199.40.72.0 y que tiene 20 bits en el prefijo de red. La mascara 255.255.240.0 (11111111.11111111.11110000.00000000) nos indica que se están usando 4 bits extra (los que se han resaltado) para identificar a las redes que componen al bloque. Nótese que cuatro bits permites agrupar precisamente 16 redes Clase C.

Un aspecto importante que hay que subrayar es que en ningún momento cambia el algoritmo básico de enrutamiento IP, lo que cambia es el contenido de las tablas. Además, las nuevas tablas contienen información resumida, por lo que buscar una dirección destino en la tabla se hace de otra manera, pero el algoritmo permanece inalterado.

El problema de buscar direcciones de destino en una tabla, consiste en que cualquier dirección cuya mascara de destino tenga menos bits, incluye a la que tiene mas bits. Con esto quiero decir que una mascara de subred como 255.255.0.0 (11111111.11111111.00000000.00000000, es decir, 16 bits de prefijo de red) incluye dentro de si a la mascaras de subred 255.255.128.0 (11111111.11111111.10000000.00000000, 17 bits de prefijo de red) y esta a su ves incluye a la mascara 255.255.192.0 (11111111.11111111.11000000.00000000) y en general, entre menos bits tiene el prefijo de red, mas direcciones Host abarca. Por esta razón cuando se explora la tabla de enrutamiento IP en busca de una dirección de destino, se hace una búsqueda que inicia con las mascaras de más bits y termina en la de menos bits. Es decir, se inicia con mascaras como 255.255.255.255 (todo en uno) y se continua con la 255.255.255.254 (31 unos y un cero) y así sucesivamente. Esto quiere decir que tendrían que hacerse 32 recorridos secuenciales a la tabla, lo cual es muy ineficiente en cuanto a tiempo, pues además de ser un procedimiento demorado, se sabe ya que direcciones normales de Clase B (255.255.0.0) requieren 16 barridos a la tabla, además, hacen falta 32 barridos para notar que no hay una entrada en la tabla para esas dirección. Por esta razón se emplean otros métodos para hacer estas búsquedas en las tablas de enrutamiento IP. Un esquema muy popular emplea un Arbol Binario, en el cual cada bit representa una nueva rama en el árbol. Así, en nuestro ejemplo, podrían dividirse las direcciones asignadas a la organización (4.096) en subredes de esta forma: dos subredes de 1.024 direcciones cada una, tres de 512 y dos de 256 direcciones. De esta forma, el árbol resultante tendría esta forma:

7


ICMP: Protocolo de Mensajes de Control de Interred (Internet Control Message Protocol)

Si un Router no puede enrutar o entregar un Datagrama, o si detecta una situación anómala que afecta su capacidad de hacerlo (por ejemplo, la congestión), debe informar a la fuente original para que evite o solucione el problema.

ICMP es un mecanismo para realizar esta operación. Es considerado como una parte obligatoria de IP y debe ser incluido en todas sus implementaciones. ICMP comunica la capa de Interred de una maquina con la misma capa en otra maquina. ICMP es un protocolo de reporte de errores (no los corrige), además, ICMP solo puede informar del error a la fuente del Datagrama, es esta maquina la que debe implementar mecanismos para enfrentar el problema.

8


Los mensajes de ICMP requieren doble encapsulacion: Los mensajes ICMP viajan empaquetados en Datagramas IP. Aun así, no se considera a ICMP un protocolo de

nivel superior a IP.

Formato del Mensaje ICMP

Aunque cada tipo de mensaje tiene su propio formato, todos ellos comparten los primeros tres campos: TIPO (8 bits), CODIGO (8 bits) y CHECKSUM (16 bits).

El campo TIPO identifica al tipo de mensaje ICMP y determina su formato. Puede tener alguno de estos valores:

• 0 : Respuesta de Eco (Echo Replay)• 3 : Destino Inaccesible (Host Unreachable)• 4 : Acallamiento de Origen (Source Quench)• 5 : Redireccionar (Redirect)• 8 : Solicitud de Eco (Echo Request)• 11 : Tiempo Excedido• 12 : Problema de Parámetros• 13 : Solicitud de Timestamp• 14 : Respuesta de Timestamp• 17 : Solicitud de mascara de subred• 18 : Respuesta de mascara de subred

Mensajes Solicitud de Eco y Respuesta al Eco

Este es el tipo de mensaje que envía la maquina cuando se emplea el comando ping. Solicitud de Eco pide a la maquina destino que responda con una Respuesta de Eco con un numero de secuencia apropiado.

TIPO (8 o 0) CODIGO (0) CHECKSUM Identificador Numero de Secuencia

Datos Opcionales

9


Mensaje Destino Inaccesible.

Es el mensaje empleado para reportar que no es posible entregar un Datagrama. El campo CODIGO describe mejor el problema:

• 0 : Red Inaccesible• 1 : Host Inaccesible• 2 : Protocolo Inaccesible• 3 : Puerto Inaccesible• 4 : Necesita Fragmentación• 5 : Falla en la Ruta de Origen• 6 : Red de Destino Desconocida• 7 : Host Destino Desconocido• 8 : Host de Origen Aislado• 9 : Comunicación con Red Destino Administrativamente Prohibida• 10 : Comunicación con Host Destino Administrativamente Prohibida• 11 : Red Inaccesible por el tipo de servicio• 12 : Host Inaccesible por el tipo de servicio

TIPO (3) CODIGO (0...12) CHECKSUMNO – USADO (debe ser cero)

Encabezado IP + Primeros 8 bytes de Datos IP

Los errores de red inaccesible por lo general implican fallas de enrutamiento. Debido a que el mensaje ICMP contiene la cabecera del Datagrama que lo produjo (en el campo de datos), el origen sabrá cual destino es inaccesible.

Mensaje de Acallamiento de Origen

Debido a que IP funciona sin conexión un Router no puede reservar memoria o recursos de comunicación antes de recibir los Datagramas. En consecuencia los Routers pueden verse repentinamente saturados por el trafico. A esta situación se le llama congestión.

El congestionamiento se da por que un Host de alta velocidad genera Datagramas mas rápido de lo que el Router puede manejar o porque muchos Host envían Datagrama a la misma dirección al mismo tiempo.

10


Cuando los Datagramas llegan mas rápido de lo que un Router puede manejarlos, este los coloca en un buffer. Si los Datagramas son parte de una ráfaga pequeña, esto soluciona el problema, pero si continúan llegando Datagramas se saturan los buffers y el Router debe descartar los nuevos Datagramas. Es entonces cuando el Router genera un mensaje ICMP de Acallamiento de Origen solicitando a este reducir la tasa de envío de Datagramas. No existe un mensaje ICMP para revertir esta solicitud, en general poco después de bajar la tasa de envío, los Hosts la aumentan progresivamente hasta recibir otro mensaje de Acallamiento de Origen.

TIPO (4) CODIGO (0) CHECKSUMNO UTILIZADO (debe ser cero)

Encabezado IP + 8 primeros bytes de Datos IP

El objetivo de este mensaje era aliviar el problema de la congestión, pero no tuvo éxito. Se dejo al implementador decidir sobre cuando enviar estos mensajes, por lo que cada fabricante emplea su política favorita sin que ninguna solucione el problema del todo. Por otra parte, ICMP informa al Host de origen que su Datagrama ha sido descartado, pero puede que este Host no sea el causante de la congestión. Además, Como responder al mensaje ICMP?. Documentos como Requisitos para los Routers (RFC 1812) estipulan que NO se deben enviar mensajes de Acallamiento de Origen. Se esta trabajando en mecanismos mas eficientes.

Mensaje Redireccionar

Se asume que los Routers conocen rutas correctas. Los Host comienzan con información mínima de enrutamiento y aprenden nuevas rutas de los Routers. En caso de que un Host utilice una ruta no optima, el Router que lo detecta envía un mensaje ICMP Redireccionar solicitándole que actualice su tabla de enrutamiento IP.

TIPO (5) CODIGO (0...3) CHECKSUMDirección IP del Router

Encabezado de IP + 8 primeros bytes de Datos IP

Mensaje Tiempo Excedido

Debido a que los Routers solo deciden sobre el próximo “Salto” usando tablas locales, errores en esas tablas pueden generar “ciclos de enrutamiento” para algún destino. Esto provoca que los Datagramas sean descartados por vencimiento de su TTL. Siempre que un Router descarte un Datagrama ya sea por vencimiento de TTL o por vencimiento del Tiempo de Reensamblado, envía un mensaje de Tiempo Excedido a la fuente.

11


TIPO (11) CODIGO (0 o 1) CHECKSUMNO – UTILIZADO (debe ser cero)


CODIGO = 0: Descartado por vencimiento de TTLCODIGO = 1: Descartado por vencimiento de Tiempo de Reensamblado.

Mensaje Problema de Parámetros

Cuando un Router o un Host encuentra un problema que no ha sido cubierto con los mensajes ICMP anteriores, envía este mensaje.

TIPO (12) CODIGO (0 o 1) CHECKSUMIndicador NO – Utilizado (debe ser cero)


El campo indicador apunta al campo dentro del encabezado IP que generó el problema.

Mensaje Solicitud de Timestamp y Respuesta de Timestamp

Una técnica sencilla provista por TCP/IP para sincronizar relojes emplea ICMP para obtener la hora de la otra maquina. Una maquina envía a otra una solicitud de Timestamp, solicitándole que informe su valor actual para la hora del día. La otra maquina envía una respuesta de Timestamp con esa información.

TIPO (13 o 14) CODIGO (0) CHECKSUMIdentificador Numero de Secuencia

Timestamp OrigenTimestamp al Recibir

Timestamp al Transmitir

Mensaje Solicitud de Mascara de Subred y Respuesta de Mascara de Subred

Para aprender la mascara de subred utilizada por la red local, una maquina puede enviar un mensaje ICMP Solicitud de Mascara de Subred a un Router y esperar su Respuesta. Si la maquina no conoce la dirección del Router, puede enviar este mensaje por difusión.

12


TIPO (17 o 18) CODIGO (0) CHECKSUMIdentificador Numero de Secuencia

Mascara de Subred

Dirección IP

Una dirección IP es un número que identifica a una interfaz de un dispositivo (habitualmente un ordenador) dentro de una red que utilice el protocolo IP.

Es habitual que un usuario que se conecta desde su hogar tenga una dirección IP que cambia cada cierto tiempo; eso es una dirección IP dinámica (normalmente se abrevia como IP dinámica).

Los sitios de Internet que están permanentemente conectados generalmente tienen una dirección IP fija (se aplica la misma reducción por IP fija), es decir, no cambia con el tiempo y esto facilita la resolución de nombres con el Servicio DNS: los humanos recordamos más fácilmente palabras con sentido que largas secuencias de números, pero las máquinas tienen una gran facilidad para manipular y jerarquizar la información numérica, y son altamente eficientes para hacerlo.

También hay la posibilidad de que un usuario doméstico del internet cuente con una dirección IP fija. Esto depende de si su ISP (proveedor de internet) utiliza DHCP (Dynamic Host Configuration Protocol) o no. Si emplea DHCP, entonces la dirección IP sí va a cambiar.

Subredes

Cuando se trabaja con una red pequeña, con pocos host conectados, el adminitrador de red puede fácilmente configurar el rango de direcciones IP usado para conseguir un funcionamiento óptimo del sistema. Pero conforme la red va creciendo se hace necesaria una división en partes de la misma.

En primer lugar, porque conforme se va extendiendo la red va aumentando de forma pareja el dominio de colisión, llegando un momento en el que el rendimiento de la red se ve afectado seriamente. Esto se puede mitigar segmentando la red, dividiendo la misma en una serie de segmentos significativos, de tal forma que mediante switches podremos limitar estos dominios de colisión, enviando las tramas tan sólo al segmento en el que se encuentra el host destino.

13

http://es.wikipedia.org/wiki/Interfaz_de_red

http://es.wikipedia.org/wiki/DHCP

http://es.wikipedia.org/wiki/DNS

http://es.wikipedia.org/wiki/Direcci?n_IP_fija

http://es.wikipedia.org/wiki/Direcci?n_IP_din?mica

http://es.wikipedia.org/wiki/Protocolo_de_Internet

http://es.wikipedia.org/wiki/Red_de_computadoras


En segundo lugar, y aunque segmentemos la red, conforme aumenta el número de host aumenta también el número de transmisiones de broadcast (cuando un equipo origen envía datos a todos los dispositivos de la red), llegando un momento que dicho tráfico puede congestionar toda la red de forma inaceptable, al consumir un ancho de banda excesivo. Esto es así porque todos los host están enviando de forma constante peticiones de este tipo: peticiones ARP, envíos RIP, peticiones DNS, etc.

Para solventar este hecho es preciso dividir la red primaria en una serie de subredes, de tal forma que cada una de ellas va a funcionar luego, a nivel de envío y recepción de paquetes, como una red individual, aunque todas pertenezcan a la misma red principal (y por lo tanto, al mismo dominio). De esta forma, aunque la red en su conjunto tendrá una dirección IP única, administrativamente, a nivel administrativo podremos considerar subredes bien diferenciadas, consiguiendo con ello un control del tráfico de la red y una limitación de las peticiones de broadcast que la atraviesan.

En las explicaciones siguientes vamos a considerar una red pública, es decir, formada por host con direcciones IP públicas, que pueden ser vistas por todos las máquinas conectadas a Internet. Pero el desarrollo es igualmente válido para redes privadas, por lo que su aplicación práctica es válida para toda red corporativa. Y para hacer más claro el desarrollo, vamos a parir de una red con dirección IP real.

Vamos a tomar como ejemplo una red de clase C, teniendo claro que lo que expliquemos va a ser útil para cualquier tipo de red, séa de clase A, B o C. Entonces, tenemos nuestra red, con dirección IP 210.25.2.0, por lo que tenemos para asignar a los host de la misma todas las direcciones IP del rango 210.25.2.1 al 210.25.2.254, ya que la dirección 210.25.2.0 será la de la propia red y la 210.25.2.255 será la dirección de broadcast general.

Si expresamos nuestra dirección de red en binario tendremos:

210.25.2.0 = 11010010.00011001.00000010.00000000

Con lo que tenemos 24 bits para identificar la red (en granate) y 8 bits para identificar los host (en azul).

La máscara de red será:

11111111.11111111.11111111.00000000 = 255.255.255.0

Para crear subredes a partir de una dirección IP de red padre, la idea es "robar" bits a los host, pasándolos a los de identificación de red. ¿Cuántos?. Bueno, depende de las subredes que queramos obtener, teniendo en cuenta que cuántas más bits robemos, más subredes obtendremos, pero con menos host cada una. Por lo tanto, el número de bits a robar depende de las necesidades de funcionamiento de la red final.

14


Máscara de subred.

Otro elemento que deberemos calcular para cada una de las subredes es su máscara de subred, concepto análogo al de máscara de red en redes generales, y que va a ser la herramienta que utilicen luego los routers para dirigir correctamente los paquetes que circulen entre las diferentes subredes.

Para obtener la máscara de subred basta con presentar la dirección propia de la subred en binario, poner a 1 todos los bits que dejemos para la parte de red (incluyendo los robados a la porción de host), y poner a 0 todos los bits que queden para los host. Por último, pasaremos la dirección binaria resultante a formato decimal separado por puntos, y ésa será la máscara de la subred.

Por ejemplo, si tenemos la dirección de clase B:

150.10.x.x = 10010110.00001010.hhhhhhhh.hhhhhhhh

y le quitamos 4 bits a la porción de host para crear subredes:

10010110.00001010.rrrrhhhh.hhhhhhhh

la máscara de subred será:

11111111.11111111.11110000.000000

que pasada a decimal nos queda:

255.255.240.0

Las máscaras de subred, al igual que ocurre con las máscaras de red, son muy importantes, resultando imprescindibles para el trabajo de enrutamiento de los routers.

Creando las subredes.

Vamos a partir pués de nuestra dirección IP de la red padre y vamos a ir quitando bist sucesivos a la porción de host, calculando en cada caso las subredes obtenidas, sus direcciones IP, sus máscaras de subred y el rendimiento de la partición obtenida.

Para ello, pasamos la dirección IP a binario, cogemos los bits robados a la porción de host y vamos variando de todas las formas posibles:

0000, 0001, 0010, 0011, 0100, 0101, 0110, 0111

En el caso de 4 bits, y luego calculamos las IP de los host correspondientes a cada una de las variaciones hallando los márgenes de las mismas, ya que estarán entre el valos mínimo y el máximo al variar los bits de la porción de host entre todos 0 (dirección de subred) y todos 1 (dirección de broadcast correspondiente).

15


Robo de 1 bit:

Si quitamos un sólo bit a la parte de host:

parte de red: 11010010.00011001.00000010.r

parte de host: hhhhhhh

Permutando los bits de host robados para obtener las subredes obtenidas:

21=2

Es decir, 2 subredes (11010010.00011001.00000010.0 y 11010010.00011001.00000010.1 ). Pero resulta que no podemos disponer de la subred que toma el 0, ya que entonces contendría la IP de la red padre, ni de la que toma el 1, ya que contendría la dirección de broadcast de la red padre. Es decir, robando 1 sólo bit no podemos crear subredes.

Como regla general, el número de subredes obtenidas al quitar n bits a la porción de host será 222, y el número de host disponible en cada subred será 2(8n)2, ya que toda subred debe tener su propia dirección de red y su propia dirección de broadcast.

Si vamos aumentando el número de bits robados a la proción de host obtenemos:

Robo de 2 bits:

parte de red: 11010010.00011001.00000010.rr

parte de host: hhhhhh

número de subredes válidas: 222=2

número de host válidos por subred: 262=62

Las direcciones de subred las obtenemos haciendo las combinaciones posibles con los 2 bits robados:

11010010.00011001.00000010. 00 000000 a 11010010.00011001.00000010. 00 111111 =210.25.2.0 a 210.25.2.63 (no vale, al contener la dirección de red de la red padre).

11010010.00011001.00000010.01000000 a 11010010.00011001.00000010.01111111 = 210.25.2.64 a 210.25.2.127

16


Subred válida, con dirección de red=210.25.2.64, broadcast=210.25.2.127 y 62 direcciones IP para host, que son las comprendidas entre las dos anteriores (de la 210.25.2.65 a la 210.25.2.126).

Máscara de subred:

11111111.11111111.11111111.11000000 = 255.255.255.192

11010010.00011001.00000010.10 000000 a 11010010.00011001.00000010.10 111111 = 210.25.2.128 a 210.25.2.191


Máscara de subred:

11111111.11111111.11111111.11000000 = 255.255.255.192

11010010.00011001.00000010.11 000000 a 11010010.00011001.00000010. 11111111 = 210.25.2.192 a 210.25.2.225 (no vale, al contener la dirección de broadcast de la red padre).

Resumiendo: obtenemos dos subredes válidas, con 62 direcciones IP válidas cada una, es decir, desperdiciamos:

(2562)(62+62)=130

Direcciones IP para host, con lo que el rendimiento de la partición en subredes será:

R=(IP útiles subredes)/(IP útiles totales)=124/254=0.488=48%

Como véis, la máscara de subred es la misma para todas las subredes obtenidas robando 2 bist a la porción de host, y lo mismo ocurre para el robo de otro número de bits.

Robo de 3 bits:

parte de red: 11010010.00011001.00000010.rrr

parte de host: hhhhh

número de subredes válidas: 232=6

número de host válidos por subred: 252=30

Las direcciones de subred las obtenemos haciendo las combinaciones posibles con los 3 bits robados:

11010010.00011001.00000010. 00000000 a 11010010.00011001.00000010.000 11111 (no vale, al contener la dirección de red de la red padre).

17


11010010.00011001.00000010.001 00000 a 11010010.00011001.00000010. 00111111 = 210.25.2.32 a 210.25.2.63


11010010.00011001.00000010.010 00000 a 11010010.00011001.00000010.010 11111 = 210.25.2.64 a 210.25.2.95


11010010.00011001.00000010.011 00000 a 11010010.00011001.00000010.011 11111 = 210.25.2.96 a 210.25.2.127


11010010.00011001.00000010.100 00000 a 11010010.00011001.00000010.100 11111 = 210.25.2.128 a 210.25.2.159


11010010.00011001.00000010.101 00000 a 11010010.00011001.00000010.101 11111 = 210.25.2.160 a 210.25.2.191


11010010.00011001.00000010.110 00000 a 11010010.00011001.00000010.110 11111 = 210.25.2.192 a 210.25.2.223


11010010.00011001.00000010. 11100000 a 11010010.00011001.00000010. 11111111 = 210.25.2.224 a 210.25.2.255 (no vale, al contener la dirección de broadcast de la red padre).

18


Máscara de subred para todas ellas:

11111111.11111111.11111111.11100000 = 255.255.255.224

Resumiendo: obtenemos6 subredes válidas, con30 direcciones IP válidas para host cada una, es decir, desperdiciamos:

(2562)(30+30+30+30+30+30)=74

Direcciones IP para host, con lo que el rendimiento de la partición en subredes será:

R=(IP útiles subredes)/(IP útiles totales)=180/254=0.708=70.8%

Y lo mismo hacemos en el caso de robar 4, 5 y 6 bits (7 no podemos robar, ya que entoneces las subredes resultantes sólo podrían tener 2 direcciones IP, una para la subred y otra de broadcast, con lo que no podrían tener host).

Cada vez que se pide prestado otro bit del campo de host, la cantidad de subredes totales posibles se duplica, mientras que la cantidad de direcciones de host totales que se pueden asignar se reduce a la mitad (aunque la cantidad de redes y host útiles varía un poco de esta regla: 2 menos en todo caso).

Un patrón de equivalencia decimalbinario a la hora de calcular máscaras de subred es el siguiente:

En cualquier caso, y una vez realizada la partición, la primera dirección IP válida de la misma se suele asignar al router que unirá las diferentes subredes.

Optimizando la partición.

Es tarea del diseñador de la red o del administrador de la misma el obtener la partición en subredes más acertada de acuerdo con las necesidades actuales y futuras, con objeto de optimizar el número de IPs utilizadas, sobre todo en el caso de que la red séa pública.

Por un lado, se pueden precisar subredes con unas necesidades de host predeterminadas (p.e. 50 host por subred, 120, etc.), por otro se debe procurar que el número de IPs desperdiciadas séa mínimo, y por otro lado se deben limitar al máximo el ancho de banda absorvido por las peticiones de broadcast.

Por lo tanto, se hace preciso un cálculo exacto de las diferentes obciones disponibles, buscando que el rendimiento de la partición séa máximo, dentro de las necesidades exigidas a la partición. Un resumen de los rendimientos (direcciones ) lo tenñeis en la siguiente tabla:

19


De todas formas, el caso más normal con el que nos encontraremos será una empresa u organización con una o varias direcciones IP públicas, asignadas por su ISP (Proveedor de Servicios de Internet), que serán usadas por router/firewall, encargados de dar salida a Internet a todos los host internos. Trás los routers habrá normalmente uno o más servidores Proxi, que serán los que se encargarán de gestionar las peticiones de servicios externos de los host, y trás el tendremos una red interna, privada, formada por diferentes host, servidores de aplicaciones, servidores de datos, impresoras, etc.

En estos casos, el administrador o diseñador de la red interna dispondrá de todo un rango de IPs disponibles para realizar las particiones, pudiendo usar la clase IP privada (clase A, B o C) que más le convenga. No obstante, es muy importante también el cálculo óptimo de la partición, a fin de limitar al máximo los dominios de colisión y el ancho de banda consumido los broadcast.

Existen para ello direcciones IP reservadas, privadas, para usos internos, que se establecieron por convenio. Estas direcciones no son vistas desde el exterior, no son públicas, y sus rangos son:

Clase A: 10.0.0.0

ClaseB: 172.16.0.0 a 172.31.0.0

Clase C: 192.168.X.0 (con X variando).

20


Protocolo ICMP (Control de Internet)

Debido a que el protocolo IP no es fiable, los datagramas pueden perderse o llegar defectuosos a su destino. El protocolo ICMP (Internet Control Message Protocol, protocolo de mensajes de control y error) se encarga de informar al origen si se ha producido algún error durante la entrega de su mensaje. Pero no sólo se encarga de notificar los errores, sino que también transporta distintos mensajes de control.

Nota: El protocolo ICMP está definido en la RFC.

El protocolo ICMP únicamente informa de incidencias en la red pero no toma ninguna decisión. Esto será responsabilidad de las capas superiores. Los mensajes ICMP viajan en el campo de datos de un datagrama IP, como se puede apreciar en el siguiente esquema:

Tipo Datos ICMP

Encabezado del datagrama

Área de datos del datagrama IP

Encabezado de la trama

Área de datos de la trama Final de la trama

Debido a que el protocolo IP no es fiable puede darse el caso de que un mensaje ICMP se pierda o se dañe. Si esto llega a ocurrir no se creará un nuevo mensaje ICMP sino que el primero se descartará sin más.

Los mensajes ICMP comienzan con un campo de 8 bits que contiene el tipo de mensaje, según se muestra en la tabla siguiente. El resto de campos son distintos para cada tipo de mensaje ICMP.

Nota: El formato y significado de cada mensaje ICMP está documentado en la RFC 792.

21


Campo de tipo Tipo de mensaje ICMP 0 Respuesta de eco (Echo Reply)3 Destino inaccesible (Destination Unreachable)4 Disminución del tráfico desde el origen (Source Quench)5 Redireccionar (cambio de ruta) (Redirect)8 Solicitud de eco (Echo)

11 Tiempo excedido para un datagrama (Time Exceeded)12 Problema de Parámetros (Parameter Problem)13 Solicitud de marca de tiempo (Timestamp)14 Respuesta de marca de tiempo (Timestamp Reply)15 Solicitud de información (obsoleto) (Information Request)16 Respuesta de información (obsoleto) (Information Reply)17 Solicitud de máscara (Addressmask)18 Respuesta de máscara (Addressmask Reply)

Solicitud y respuesta de eco

Los mensajes de solicitud y respuesta de eco, tipos 8 y 0 respectivamente, se utilizan para comprobar si existe comunicación entre 2 hosts a nivel de la capa de red. Estos mensajes comprueban que las capas física (cableado), acceso al medio (tarjetas de red) y red (configuración IP) están correctas. Sin embargo, no dicen nada de las capas de transporte y de aplicación las cuales podrían estar mal configuradas; por ejemplo, la recepción de mensajes de correo electrónico puede fallar aunque exista comunicación IP con el servidor de correo.

La orden PING envía mensajes de solicitud de eco a un host remoto e informa de las respuestas. Veamos su funcionamiento, en caso de no producirse incidencias en el camino.

1. A envía un mensaje ICMP de tipo 8 (Echo) a B

2. B recibe el mensaje y devuelve un mensaje ICMP de tipo 0 (Echo Reply) a A

3. A recibe el mensaje ICMP de B y muestra el resultado en pantalla

A>ping 172.20.9.7 n 1Haciendo ping a 172.20.9.7 con 32 bytes de datos:Respuesta desde 172.20.9.7: bytes=32 tiempo<10ms TDV=128

22


En la orden anterior hemos utilizado el parámetro "n 1" para que el host A únicamente envíe 1 mensaje de solicitud de eco. Si no se especifica este parámetro se enviarían 4 mensajes (y se recibirían 4 respuestas).

Si el host de destino no existiese o no estuviera correctamente configurado recibiríamos un mensaje ICMP de tipo 11 (Time Exceeded).

A>ping 192.168.0.6 n 1Haciendo ping a 192.168.0.6 con 32 bytes de datos:Tiempo de espera agotado.

Si tratamos de acceder a un host de una red distinta a la nuestra y no existe un camino

para llegar hasta él, es decir, los routers no están correctamente configurados o estamos

intentando acceder a una red aislada o inexistente, recibiríamos un mensaje ICMP de tipo 3

(Destination Unreachable).

A>ping 1.1.1.1 n 1Haciendo ping a 1.1.1.1 con 32 bytes de datos:Respuesta desde 192.168.0.1: Host de destino inaccesible.

Utilización de PING para diagnosticar errores en una red aislada

A>ping 192.168.1.12

• Respuesta. El cableado entre A y B, las tarjetas de red de A y B, y la configuración IP de A y B están correctos.

• Tiempo de espera agotado. Comprobar el host B y el cableado entre A y B.

• Host de destino inaccesible. Comprobar las direcciones IP y máscaras de subred de A y B porque no pertenecen a la misma red.

• Error. Probablemente estén mal instalados los protocolos TCP/IP del host A. Probar A>ping 127.0.0.1 para asegurarse.

23


Nota: El comando ping 127.0.0.1 informa de si están correctamente instalados los protocolos TCP/IP en nuestro host. No informa de si la tarjeta de red de nuestro host está correcta.

Utilización de PING para diagnosticar errores en una red de redes

A continuación veremos un ejemplo para una red de redes formada por dos redes (1 solo router). La idea es la misma para un mayor número de redes y routers.

A>ping 10.100.5.1

• Respuesta. El cableado entre A y B, las tarjetas de red de A, R1 y B, y la configuración IP de A, R1 y B están correctos. El router R1 permite el tráfico de datagramas IP en los dos sentidos.

• Tiempo de espera agotado. Comprobar el host B y el cableado entre R1 y B. Para asegurarnos que el router R1 está funcionando correctamente haremos A>ping 192.168.1.1

• Host de destino inaccesible. Comprobar el router R1 y la configuración IP de A (probablemente la puerta de salida no sea 192.168.1.1). Recordemos que la puerta de salida (gateway) de una red es un host de su propia red que se utiliza para salir a otras redes.

• Error. Probablemente estén mal instalados los protocolos TCP/IP del host A. Probar A>ping 127.0.0.1 para asegurarse.

En el caso producirse errores de comunicación en una red de redes con más de un router (Internet es el mejor ejemplo), se suele utilizar el comando PING para ir diagnosticando los distintos routers desde el destino hasta el origen y descubrir así si el fallo es responsabilidad de la red de destino, de una red intermedia o de nuestra red.

Nota: Algunos hosts en Internet tienen deshabilitadas las respuestas de eco (mensajes ICMP tipo 0) como medida de seguridad. En estos casos hay que utilizar otros mecanismos para detectar si responde (por ejemplo, la apertura de conexión a un puerto, como veremos en el capítulo siguiente).

24


Mensajes ICMP de tiempo excedido

Los datagramas IP tienen un campo TTL (tiempo de vida) que impide que un mensaje esté dando vueltas indefinidamente por la red de redes. El número contenido en este campo disminuye en una unidad cada vez que el datagrama atraviesa un router. Cuando el TTL de un datagrama llega a 0, éste se descarta y se envía un mensaje ICMP de tipo 11 (Time Exceeded) para informar al origen.

Los mensajes ICMP de tipo 11 se pueden utilizar para hacer una traza del camino que siguen los datagramas hasta llegar a su destino. ¿Cómo? Enviando una secuencia de datagramas con TTL=1, TTL=2, TTL=3, TTL=4, etc... hasta alcanzar el host o superar el límite de saltos (30 si no se indica lo contrario). El primer datagrama caducará al atravesar el primer router y se devolverá un mensaje ICMP de tipo 11 informando al origen del router que descartó el datagrama. El segundo datagrama hará lo propio con el segundo router y así sucesivamente. Los mensajes ICMP recibidos permiten definir la traza.

25

http://www.saulo.net/pub/tcpip/b.htm#2-5


Protocolo multicast (Sobre redes híbridas)

Para extender los protocolos multicast al caso de redes híbridas vamos a utilizar una versión modificada del CBT, al cuál nos referiremos como HCBT (Hybrid CoreBased Trees). La estructura del HCBT se basa en el escenario mostrado en la figura 1, donde tenemos:

• N usuarios que desean formar parte de un grupo multicast.

• De estos N usuarios, H son HHs estáticos y NH son usuarios terrestres sobre el MBONE.

• De los H usuarios, L están ligados a una LAN y HL permanecen solos. Hay que tener en cuenta que las LANs también tienen acceso a la MBONE.

• Los HHs ligados a una LAN pueden tener la responsabilidad de hacer llegar los paquetes a los usuarios finales.

• Una versión modificada del IGMP se ejecuta entre los HHs y las pasarelas.

Vamos a considerar dos tipos de tráfico: todo el tráfico por debajo de cierto umbral (T bits/seg) lo consideraremos tráfico lento, mientras que el que supere ese umbral lo consideraremos tráfico rápido. Todos lo HHs se unirán a un árbol multicast a través de una pasarela híbrida multicast (MHGW). Necesariamente todo el tráfico encaminado hacia y desde los HHs será encaminado por el MHGW. Cuando enviamos paquetes a un grupo (multicasting) que posea HHs, el MHGW observará el ancho de banda requerido y en función de éste les enviará los datos vía terrestre o vía satélite. Debido a que los paquetes enviados por satélite son difundidos de forma broadcast, éstos paquetes son disponibles para todos de forma que algún mecanismo de autentificación se requiere para permitir que reciban los paquetes sólo los HHs que pertenecen al grupo. Cuando un HH se registra con el MHGW para formar parte de algún grupo multicast, el MHGW le envia una llave especial que se usará para recibir mensages. La otra alternativa es que el MHGW envíe una copia unicast a cada miembro del grupo, lo cual desaprovecha claramente el ancho de banda del enlace descendente del satelite.

Los HHs que están unidos a una LAN, tendrán que ejecutar un proxy para permitirles actuar como un router multicast a efectos de la LAN.

26

http://www.upv.es/satelite/trabajos/Grupo8_99.00/multicast.html#cbt


Basamos en el CBT

Si pensamos en un protocolo de encaminamiento para ser usado sobre redes híbridas, hay que observar con cuidado las características únicas que poseen este tipo de redes, y hacer uso de su naturaleza asimétrica. La mejor forma de empezar podría ser modificar un protocolo existente con el fin de acomodarlo a leste tipo de redes. El protocolo de encaminamiento multicast más utilizado es el DVMRP; pero la naturaleza asimétrica del tráfico en redes híbridas elimina prácticamente la posibilidad de utilizar un protocolo basado en la distancia de vectores. De los protocolos existentes el que mejor se adapta a las características que queremos es el CBT (CoreBased Trees; protocolo basado en árboles de distribución); veamos esas características del CBT que lo hacen deseable frente a otros protocolos:

• Retardo mínimo. El retardo introducido por el satélite puede ser relevante. La arquitectura del CBT que encamina todo el tráfico multicast hacia los núcleos (cores) del árbol de distribución, sugiere que con una selección cuidadosa de estos núcleos podamos minimizar el retardo introducido en los árboles del CBT.

• Posibilidad de que la fuente no pertenezca al grupo; ésta es uno de los atractivos más importantes del CBT frente a otros protocolos.

• Escalabilidad. Esta escalabilidad es posible gacias a la mayor simplicidad que posee el CBT frene a otros protocolos.

• Interoperabilidad. Esto es debido a que el CBT asume que la región es heterogénea, con los routers usando protocolos de encaminamiento diferentes.

• Independencia del protocolo de encaminamiento. La mayoría de los protocolos multicast dependen del protocolo unicast sobre el que se ejecuten. Pero esta dependencia del protocolo unicast puede ser un problema, ya que los diferentes hosts destinos de los paquetes multicast pueden pertenecer a redes con diferentes protocolos. El protocolo CBT construye su árbol multicast con independencia del protocolo de encaminamiento unicast, lo cual presenta grandes ventajas.

27


Especificaciones del protocolo.

Para la arquitectura del HCBT propuesta, todo el encaminamiento multicast hacia y desde los terminales híbridos se hace a través del MHGW. Los HHs deben de ejecutar una versión modificada del IGMP para permitir al MHGW saber los miembros de cada grupo. Además, aquellos HHs que actúen como routers dentro de su LAN, deberán ejecutar un proxy para conocer la información de los miembros del grupo de su LAN y pasarla al MHGW. Estos HHs especiales serán también los responsables de que los paquetes multicast lleguen a los miembro de su LAN. El MHGW debe de poder soportar el protocolo CBT para poder unir al correspondiente árbol multicast a los HHs. La elegancia de la arquitectura propuesta recae en su capacidad de hacer un encaminamiento inteligente dependiendo del tipo de tráfico. Para poder soportar esta característica deseable, el MHGW debe de implementar un mecanismo que encamine los paquetes del tráfico rápido a través del satélite y los paquetes del tráfico lento a través de los enlaces de cable terrestres; esto será equivalente a mantener dos árboles multicast de entrega separados. Para establecer un mecanismo de entrega multicast fiable que garantice "al menos una" entrega de los paquetes multicast, el MHGW debe mantener una copia de todos los paquetes hasta que le llegue el reconocimiento de todos los HHs. Esto se desvía de los esquemas típicos del multicast sobre IP (IGMP), donde los routers multicast sólo guardan información de la red ligada a los miembros del grupo y no de los miembros del grupo individualmente.

IGMP

El IGMP (Internet Group Membership Protocol) lo usan los routers para aprender la información de los miembros de un grupo en su subred local. Este protocolo no está enfocado hacia una red híbrida (satéliteterrestre) porque algunas de las suposiciones hechas no son validas para este escenario. Por ejemplo, el IGMP supone que todos los hosts miembros de una subred local se pueden escuchar unos a otros; pero en una red híbrida los HHs no tienen un enlace directo con los demás ya que el enlace con el satélite es unidireccional. Por tanto, habrá que modificar el IGMP para que pueda ser usado en este contexto. Quitamos la opción de interrogación por parte del IGMP y hacemos que todos los HHs manden una petición al MHGW cuando quieran unirse o dejar un grupo. Para cubrir el caso de paquetes perdidos, la petición se mandará por duplicado si la confirmación (de la primera petición) no llega en un tiempo de espera especificado. Este método puede causar problemas en la fase de inicialización o en la fase de cierre de la sesión multicast (cuando todos los HHs intenten unirse o dejar el grupo) porque el MHGW se verá inundado de mensajes de grupo, así que esta técnica es aconsejable sólo para grupos con un número pequeño de miembros HHs.

Por otra parte, si no es necesaria la fiabilidad en la entrega de paquetes, el MHGW puede reenviar las petición recibidas a través del satélite y de esta forma algunos HHs se pueden ahorrar sus peticiones.

28


Medidas en la ejecución de un protocolo multicast.

Para evaluar la ejecución de un protocolo multicast se suelen usar algunos indicadores para estimar lo bien que funciona el protocolo sobre diferentes escenarios. Para un encaminamiento dinámico multicast, es importante determinar la latencia introducida al unirse a un grupo multicast, siendo deseable que esa latencia sea la mínima posible. Pero el indicador más importante que se suele usar es el tiempo que le cuesta a cada miembro del grupo recibir los paquetes enviados, es decir, el tiempo de transferencia. Con el fin de controlar la pérdida de paquetes se han hecho muchos estudios para determinar la correlación de los paquetes perdidos dentro de una red multicast, y se observa que las perdidas en la MBONE están temporalmente correlacionadas, es decir, la mayoría de perdidas ocurren en los receptores y en los routers; y no en los enlaces. La topología de la distribución multicast (en forma de árbol) afecta también a la pérdida de paquetes y, consecuentemente, al tiempo de transferncia.

La concentración del tráfico en los enlaces del árbol de distribución también se usa como indicador. Debido al gran retardo introducido por el enlace del satélite, el indicador más importante es la demora de transferencia en la entrega de paquetes multicast hasta todos los Hosts Híbridos.

IPv6Es la versión 6 del Protocolo de Internet (Internet Protocol), un estándar del nivel de red

encargado de dirigir y encaminar los paquetes a través de una red.

Diseñado por Steve Deering de Xerox PARC y Craig Mudge, IPv6 está destinado a sustituir al estándar IPv4, cuyo límite en el número de direcciones de red admisibles está empezando a restringir el crecimiento de Internet y su uso, especialmente en China, India, y otros países asiáticos densamente poblados. Pero el nuevo estándar mejorará el servicio globalmente; por ejemplo, proporcionando a futuras celdas telefónicas y dispositivos móviles con sus direcciones propias y permanentes. Al día de hoy se calcula que las dos terceras partes de las direcciones que ofrece IPv4 ya están asignadas.

IPv4 soporta 4.294.967.296 (4,294 × 109) direcciones de red diferentes, un número inadecuado para dar una dirección a cada persona del planeta, y mucho menos para cada coche, teléfono, PDA o tostadora; mientras que IPv6 soporta 340.282.366.920.938.463.463.374.607.431.768.211.456 (3,4 x 1038 ó 340 sextillones) direcciones cerca de 4,3 x 1020 (430 trillones) direcciones por cada pulgada cuadrada (6.7 x 1017 ó 670 mil billones direcciones/mm²) de la superficie de La Tierra.

29

http://es.wikipedia.org/wiki/Tierra

http://es.wikipedia.org/wiki/Prefijos_del_SI




http://es.wikipedia.org/wiki/IPv4


http://es.wikipedia.org/wiki/Asia

http://es.wikipedia.org/wiki/India

http://es.wikipedia.org/wiki/China


http://es.wikipedia.org/w/index.php?title=Craig_Mudge&action=edit

http://es.wikipedia.org/w/index.php?title=Xerox_PARC&action=edit

http://es.wikipedia.org/w/index.php?title=Steve_Deering&action=edit

http://es.wikipedia.org/wiki/Red_de_ordenadores

http://es.wikipedia.org/wiki/Paquete_de_datos

http://es.wikipedia.org/wiki/Nivel_de_red



Adoptado por el Internet Engineering Task Force en 1994 (cuando era llamado "IP Next Generation" o IPng), IPv6 cuenta con un pequeño porcentaje de las direcciones públicas de Internet, que todavía están dominadas por IPv4. La adopción de IPv6 ha sido frenada por la traducción de direcciones de red (NAT), que alivia parcialmente el problema de la falta de direcciones IP. Pero NAT hace difícil o imposible el uso de algunas aplicaciones P2P, como son la voz sobre IP (VoIP) y juegos multiusuario. Además, NAT rompe con la idea originaria de Internet donde todos pueden conectarse con todos. Actualmente, el gran catalizador de IPv6 es la capacidad de ofrecer nuevos servicios, como la movilidad, Calidad de Servicio (QoS), privacidad, etc. El gobierno de los Estados Unidos ha ordenado el despliegue de IPv6 por todas sus agencias federales para el año 2008.

Se espera que IPv4 se siga soportando hasta por lo menos el 2025, dado que hay muchos dispositivos heredados que no se migrarán a IPv6 nunca y que seguirán siendo utilizados por mucho tiempo.

IPv6 es la segunda versión del Protocolo de Internet que se ha adoptado para uso general. También hubo un IPv5, pero no fue un sucesor de IPv4; mejor dicho, fue un protocolo experimental orientado al flujo de streaming que intentaba soportar voz, video y audio.

Direccionamiento IPv6

El cambio más drástico de IPv4 a IPv6 es la longitud de las direcciones de red. Las direcciones IPv6, definidas en el RFC 2373 y RFC 2374, son de 128 bits; esto corresponde a 32 dígitos hexadecimales, que se utilizan normalmente para escribir las direcciones IPv6, como se describe en la siguiente sección.

El número de direcciones IPv6 posibles es de 2128 3.4 x 10≈ 38. Este número puede también representarse como 1632, con 32 dígitos hexadecimales, cada uno de los cuales puede tomar 16 valores (véase combinatoria).

En muchas ocasiones las direcciones IPv6 están compuestas por dos partes lógicas: un prefijo de 64 bits y otra parte de 64 bits que corresponde al identificador de interfaz, que casi siempre se genera automáticamente a partir de la dirección MAC de la interfaz a la que está asignada la dirección.

A menudo se ha argumentado que las direcciones de 128 bits son exageradas, y que Internet nunca necesitará tantas. Debería tenerse en cuenta que el fundamento principal para las direcciones de 128 bits no solo es tener suficientes direcciones disponibles de por vida, sino también asegurar que el encaminamiento podrá ser llevado a cabo eficientemente con un esquema jerárquico que mantenga al espacio de direcciones sin fragmentar. Esto difiere de la situación actual con IPv4, donde un gran número de bloques discretos discontiguos de red pueden ser, y con frecuencia han sido, asignados a una misma organización.

30

http://es.wikipedia.org/wiki/MAC

http://es.wikipedia.org/wiki/Combinatoria

http://es.wikipedia.org/wiki/Sistema_hexadecimal

http://es.wikipedia.org/wiki/RFC

http://es.wikipedia.org/wiki/RFC

http://es.wikipedia.org/wiki/Streaming



http://es.wikipedia.org/wiki/2025


http://es.wikipedia.org/wiki/Estados_Unidos

http://es.wikipedia.org/wiki/Calidad_de_Servicio

http://es.wikipedia.org/wiki/VoIP

http://es.wikipedia.org/wiki/P2P

http://es.wikipedia.org/wiki/NAT



Notación para las direcciones IPv6

Las direcciones IPv6, de 128 bits de longitud, se escriben como ocho grupos de cuatro dígitos hexadecimales.

Por ejemplo,

2001:0db8:85a3:08d3:1319:8a2e:0370:7334

es una dirección IPv6 válida.

Si un grupo de cuatro dígitos es nulo (es decir, toma el valor "0000"), puede ser comprimido. Por ejemplo,

2001:0db8:85a3:0000:1319:8a2e:0370:7344

es la misma dirección que

2001:0db8:85a3::1319:8a2e:0370:7344

Siguiendo esta regla, si más de dos grupos consecutivos son nulos, pueden comprimirse como "::". Si la dirección tiene más de una serie de grupos nulos consecutivos la compresión solo en uno de ellos. Así,

2001:0DB8:0000:0000:0000:0000:1428:57ab2001:0DB8:0000:0000:0000::1428:57ab2001:0DB8:0:0:0:0:1428:57ab2001:0DB8:0::0:1428:57ab2001:0DB8::1428:57ab

son todas válidas y significan lo mismo, pero

2001::25de::cadenas es inválido porque no queda claro cuantos grupos nulos hay en cada lado.

Los ceros iniciales en un grupo pueden ser omitidos. Así,

2001:0DB8:02de::0e13

es lo mismo que

2001:DB8:2de::e13

Si la dirección es una dirección IPv4 camuflada, los últimos 32 bits pueden escribirse en base decimal; así,

::ffff:192.168.89.9 es lo mismo que ::ffff:c0a8:5909, pero no lo mismo que ::192.168.89.9 o ::c0a8:5909.

El formato ::ffff:1.2.3.4 se denomina dirección IPv4 mapeada, y el formato ::1.2.3.4 dirección IPv4 compatible.

31

http://es.wikipedia.org/wiki/Direcci?n_IPv4_compatible


http://es.wikipedia.org/w/index.php?title=Direcci?n_IPv4_mapeada&action=edit

http://es.wikipedia.org/wiki/Sistema_hexadecimal


Las direcciones IPv4 pueden ser transformadas fácilmente al formato IPv6. Por ejemplo, si la dirección decimal IPv4 es 135.75.43.52 (en hexadecimal, 0x874B2B34), puede ser convertida a 0000:0000:0000:0000:0000:0000:874B:2B34 o ::874B:2B34. Entonces, uno puede usar la notación mixta dirección IPv4 compatible, en cuyo caso la dirección debería ser ::135.75.43.52. Este tipo de dirección IPv4 compatible casi no está siendo utilizada en la práctica, aunque los estándares no la han declarado obsoleta.

Identificación de los tipos de direcciones

Los tipos de direcciones IPv6 pueden identificarse tomando en cuenta los primeros bits de cada dirección.

• ::/128 – la dirección con todo ceros se utiliza para indicar la ausencia de dirección, y no se asigna ningún nodo.

• ::1/128 – la dirección de loopback es una dirección que puede usar un nodo para enviarse paquetes a sí mismo (corresponde con 127.0.0.1 de IPv4). No puede asignarse a ninguna interfaz física.

• ::/96 – La dirección IPv4 compatible se usa como un mecanismo de transición en las redes duales IPv4/IPv6.

• ::ffff:0:0/96 – La dirección IPv4 mapeada es usada como un mecanismo de transición en terminales duales.

• fe80::/10 – El prefijo de enlace local (< inglés link local) específica que la dirección sólo es válida en el enlace físico local.

• fec0::/10 – El prefijo de emplazamiento local (< inglés sitelocal prefix) específica que la dirección sólo es válida dentro de una organización local. LA RFC 3879 lo declaró obsoleto, estableciendo que los sistemas futuros no deben implementar ningún soporte para este tipo de dirección especial.

• ff00::/8 – El prefijo de multicast es usado para las direcciones multicast.

Hay que resaltar que las direcciones de difusión (< inglés broadcast) no existen en IPv6, aunque la funcionalidad que prestan puede emularse utilizando la dirección multicast FF01::1, denominada todos los nodos (< inglés all nodes)

Paquetes IPv6

Estructura de la cabecera de un paquete IPv6.

32

http://es.wikipedia.org/wiki/Idioma_ingl?s

http://es.wikipedia.org/wiki/Multicast

http://es.wikipedia.org/wiki/Broadcast


http://es.wikipedia.org/wiki/Multicast

http://www.ietf.org/rfc/rfc3879.txt



http://es.wikipedia.org/w/index.php?title=Direcci?n_IPv4_mapeada&action=edit


http://es.wikipedia.org/w/index.php?title=127.0.0.1&action=edit

http://es.wikipedia.org/wiki/Loopback




Un paquete en IPv6 está compuesto principalmente de dos partes: la cabecera y los datos.

La cabecera está en los primeros 40 bytes del paquete y contiene las direcciones de origen y destino (128 bits cada una), la versión de IP (4 bits), la clase de tráfico (8 bits, Prioridad del Paquete), etiqueta de flujo (20 bits, manejo de la Calidad de Servicio), longitud del campo de datos (16 bits), cabecera siguiente (8 bits), y límite de saltos (8 bits, Tiempo de Vida). Después viene el campo de datos, con los datos que transporta el paquete, que puede llegar a 64k de tamaño en el modo normal, o más con la opción "jumbo payload".

Hay dos versiones de IPv6 levemente diferentes. La ahora obsoleta versión inicial, descrita en el RFC 1883, difiere de la actual versión propuesta de estándar, descrita en el RFC 2460, en dos campos: 4 bits han sido reasignados desde "etiqueta de flujo" (flow label) a "clase de tráfico" (traffic class). El resto de diferencias son menores.

En IPv6 la fragmentación se realiza sólo en el nodo origen del paquete, al contrario que en IPv4 en donde los routers pueden fragmentar un paquete. En IPv6, las opciones también se salen de la cabecera estándar y son especificadas por el campo "Cabecera Siguiente" (Next Header), similar en funcionalidad en IPv4 al campo Protocolo. Un ejemplo: en IPv4 uno añadiría la opción "ruta fijada desde origen" (Strict Source and Record Routing) a la cabecera IPv4 si quiere forzar una cierta ruta para el paquete, pero en IPv6 uno modificaría el campo "Cabecera Siguiente" indicando que una cabecera de encaminamiento es la siguiente en venir. La cabecera de encaminamiento podrá entonces especificar la información adicional de encaminamiento para el paquete, e indicar que, por ejemplo, la cabecera TCP será la siguiente. Este procedimiento es análogo al de AH y ESP en IPsec para IPv4 (que aplica a IPv6 de igual modo, por supuesto).

Cabeceras de extensión de IPv6

El uso de un formato flexible de cabeceras de extensión opcionales es una idea innovadora que permite ir añadiendo funcionalidades de forma paulatina. Este diseño aporta gran eficacia y flexibilidad ya que se pueden definir en cualquier momento a medida que se vayan necesitando entre la cabecera fija y la carga útil.

Hasta el momento, existen 8 tipos de cabeceras de extensión, donde la cabecera fija y las de extensión opcionales incluyen el campo de cabecera siguiente que identifica el tipo de cabeceras de extensión que viene a continuación o el identificador del protocolo de nivel superior. Luego las cabeceras de extensión se van encadenando utilizando el campo de cabecera siguiente que aparece tanto en la cabecera fija como en cada una de las citadas cabeceras de extensión. Como resultado de la secuencia anterior, dichas cabeceras de extensión se tienen que procesar en el mismo orden en el que aparecen en el datagrama. Todas o parte de estas cabeceras de extensión tienen que ubicarse en el datagrama en el orden especificado:

1. Cabecera principal, tiene el contrario que la cabecera de la versión IPv4 un tamaño fijo de 40 octetos.

33

http://es.wikipedia.org/wiki/IPsec




http://es.wikipedia.org/wiki/Tiempo_de_Vida

http://es.wikipedia.org/wiki/Calidad_de_Servicio

http://es.wikipedia.org/wiki/Paquete_de_red


2. Cabecera de opciones de salto a salto (HopbyHop), transporta información opcional, contiene los datos que deben ser examinado por cada nodo (cualquier sistema con IPv6) a través de la ruta de envió de un paquete. Su código es 0.

3. Cabecera de encaminamiento (Routing), se utiliza en para que un origen IPv6 indique uno o más nodos intermedios que se han de visitar en el camino del paquete hacia el destino. El código que utiliza es 43.

4. Encaminamiento desde la fuente.

5. Cabecera de fragmentación (Fragment), hace posible que el origen envíe un paquete más grande de lo que cabría en la MTU de la ruta (unidad máxima de transferencia). Hay que tener en cuenta que al contrario que en IPv4, en IPv6 la fragmentación de un paquete solo se puede realizar en los nodos de origen. El código empleado en esta cabecera es 44.

6. Cabecera de autenticación (Authentication Header), nos sirve para proveer servicios de integridad de datos, autenticación del origen de los datos, antireplay para IP. El código de esta cabecera es 51.

7. Cabecera de encapsulado de seguridad de la carga útil (Encapsulating Security Payload), permiten proveer servicios de integridad de datos. El código al que hace referencia esta cabecera es el 50.

8. Cabecera de opciones para el destino (Destination), se usa para llevar información opcional que necesita ser examinada solamente por los nodos destino del paquete. La última de las cabeceras utiliza el código 60.

Cada cabecera de extensión debe aparecer como mucho una sola vez, salvo la cabecera de opción destino, que puede aparecer como mucho dos veces, una antes de la cabecera encaminamiento y otra antes de la cabecera de la capa superior.

IPv6 y el Sistema de Nombres de Dominio

Las direcciones IPv6 se representan en el Sistema de Nombres de Dominio (DNS) mediante registros AAAA (también llamados registros de quadA, por analogía con los registros A para IPv4)

El concepto de AAAA fue una de las dos propuestas al tiempo que la arquitectura IPv6 estaba siendo diseñada. La otra propuesta utilizaba registros A6 y otras innovaciones como las etiquetas de cadena de bits (bitstring labels) y los registros DNAME.

Mientras que la idea de AAAA es una simple generalización del DNS IPv4, la idea de A6 fue una revisión y puesta a punto del DNS para ser más genérico, y de ahí su complejidad.

34



La RFC 3363 recomienda utilizar registros AAAA hasta tanto se pruebe y estudie exhaustivamente el uso de registros A6. La RFC 3364 realiza una comparación de las ventajas y desventajas de cada tipo de registro.

Despliegue de IPv6

El 20 de julio de 2004 la ICANN anunció que los servidores raíz de DNS de Internet habían sido modificados para soportar ambos protocolos, IPv4 e IPv6.

Desventajas:

• la necesidad de extender un soporte permanente para IPv6 a través de todo Internet y de los dispositivos conectados a ella.

• para estar enlazada al universo IPv4 durante la fase de transición, todavía se necesita una dirección IPv4 o algún tipo de NAT (compartición de direcciones IP) en los routers pasarela (IPv6<>IPv4) que añaden complejidad y que significa que el gran espacio de direcciones prometido por la especificación no podrá ser inmediatamente usado.

• problemas restantes de arquitectura, como la falta de acuerdo para un soporte adecuado de IPv6 multihoming.

Ventajas:

• Convivencia con IPv4, que hará posible una migración suave.

• Gran cantidad de direcciones, que hará virtualmente imposible que queden agotadas. Se estima que si se repartiesen en toda la superficie de la Tierra habría 6,67x1023 IPs por m².

• Direcciones unicast, multicast y anycast.

• Formato de cabecera más flexible que en IPv4 para agilizar el encaminamiento.

• Nueva etiqueta de flujo para identificar paquetes de un mismo flujo.

• No se usa checksum.

• La fragmentación y reensamblado se realiza en los nodos finales, y no en los routers como en IPv4.

• Nuevas características de seguridad. IPSEC formará parte del estándar.

• Nueva versión de ICMP, que incluye a MLD, el equivalente del IGMP de IPv4.

• Autoconfiguración de los nodos finales, que permite a un equipo aprender automáticamente una dirección IPv6 al conectarse a la red.

35

http://es.wikipedia.org/wiki/IGMP

http://es.wikipedia.org/w/index.php?title=MLD&action=edit

http://es.wikipedia.org/wiki/ICMP

http://es.wikipedia.org/wiki/Metro_cuadrado

http://es.wikipedia.org/wiki/Tierra

http://es.wikipedia.org/wiki/NAT


http://icann.org/announcements/announcement-20jul04.htm

http://es.wikipedia.org/wiki/ICANN


http://es.wikipedia.org/wiki/20_de_julio




• Movilidad incluida en el estándar, que permitirá cambiar de red sin perder la conectividad.

Mecanismos de transición a IPv6

El cambio de IPv4 a IPv6 ya ha comenzado. Durante 20 años se espera que convivan ambos protocolos y que la implantación de IPv6 sea paulatina. Existe una serie de mecanismos que permitirán la convivencia y la migración progresiva tanto de las redes como de los equipos de usuario. En general, los mecanismos de transición pueden clasificarse en tres grupos:

• Pila dual

• Túneles

• Traducción

La pila dual hace referencia a una solución de nivel IP con pila dual (RFC 2893), que implementa las pilas de ambos protocolos, IPv4 e IPv6, en cada nodo de la red. Cada nodo de pila dual en la red tendrá dos direcciones de red, una IPv4 y otra IPv6.

• Pros: Fácil de desplegar y extensamente soportado.

• Contras: La topología de red requiere dos tablas de encaminamiento y dos procesos de encaminamiento. Cada nodo en la red necesita tener actualizadas las dos pilas.

Los túneles permiten conectarse a redes IPv6 "saltando" sobre redes IPv4. Estos túneles trabajan encapsulando los paquetes IPv6 en paquetes IPv4 teniendo como siguiente capa IP el protocolo número 41, y de ahí el nombre proto41. De esta manera, los paquetes IPv6 pueden ser enviados sobre una infraestructura IPv4. Hay muchas tecnologías de túneles disponibles. La principal diferencia está en el método que usan los nodos encapsuladores para determinar la dirección a la salida del túnel.

La traducción es necesaria cuando un nodo solo IPv4 intenta comunicar con un nodo solo IPv6. Los mecanismos de traducción pueden ser divididos en dos grupos basándonos en si la información de estado está guardada:

• Con estado: NATPT[1], TCPUDP Relay[2], Socksbased Gateway[3]

• Sin estado: BumpintheStack, BumpintheAPI[4]

Actualmente el protocolo IPv6 está soportado en la mayoría de los sistemas operativos modernos, en algunos casos como una opción de instalación. Linux, Solaris, Mac OS, OpenBSD, FreeBSD, Windows (2k, CE) y Symbian (dispositivos móviles) son sólo algunos de los sistemas operativos que pueden funcionar con IPv6.

36


http://es.wikipedia.org/w/index.php?title=Bump-in-the-API&action=edit

http://es.wikipedia.org/w/index.php?title=Bump-in-the-Stack&action=edit


http://es.wikipedia.org/w/index.php?title=Socks-based_Gateway&action=edit


http://es.wikipedia.org/w/index.php?title=TCP-UDP_Relay&action=edit


http://es.wikipedia.org/w/index.php?title=NAT-PT&action=edit


http://es.wikipedia.org/wiki/Protocolos


Anuncios importantes sobre IPv6

En 2003, Nihon Keizai Shimbun informa que Japón, China y Corea del Sur han tenido la determinación de convertirse en las naciones líderes en la tecnología de Internet, que conjuntamente han dado forma parcialmente al desarrollo de IPv6, y que lo adoptarán completamente a partir de 2005.

• ICANN anunció el 20 de julio de 2004 que los registros AAAA de IPv6 para Japón (.jp) y Corea (.kr) de código de país ya son visibles en los servidores raíz de DNS. El registro IPv6 para Francia fue añadido poco después.

37

http://es.wikipedia.org/wiki/Francia


http://es.wikipedia.org/wiki/20_de_julio

http://es.wikipedia.org/wiki/ICANN


http://es.wikipedia.org/wiki/Corea

http://es.wikipedia.org/wiki/China

http://es.wikipedia.org/wiki/Jap?n

http://es.wikipedia.org/w/index.php?title=Nihon_Keizai_Shimbun&action=edit



Protocolos TCP / IP

Se han desarrollado diferentes familias de protocolos para comunicación por red de datos para los sistemas UNIX. El más ampliamente utilizado es el Internet Protocol Suite, comúnmente conocido como TCP / IP.

Es un protocolo DARPA que proporciona transmisión fiable de paquetes de datos sobre redes. El nombre TCP / IP Proviene de dos protocolos importantes de la familia, el Transmission Contorl Protocol (TCP) y el Internet Protocol (IP). Todos juntos llegan a ser más de 100 protocolos diferentes definidos en este conjunto.

El TCP / IP es la base del Internet que sirve para enlazar computadoras que utilizan diferentes sistemas operativos, incluyendo PC, minicomputadoras y computadoras centrales sobre redes de área local y área extensa. TCP / IP fue desarrollado y demostrado por primera vez en 1972 por el departamento de defensa de los Estados Unidos, ejecutándolo en el ARPANET una red de área extensa del departamento de defensa.

Las capas conceptuales del software de protocolos

Pensemos los módulos del software de protocolos en una pila vertical constituida por capas. Cada capa tiene la responsabilidad de manejar una parte del problema.

RED

38

EMISOR

CAPA N

...

CAPA 2

CAPA 1,

RECEPTOR

CAPA N

...

CAPA 2

CAPA 1,

MODELO 1


Conceptualmente, enviar un mensaje desde un programa de aplicación en una maquina hacia un programa de aplicaciones en otra, significa transferir el mensaje hacia abajo, por las capas sucesivas del software de protocolo en la maquina emisora, transferir un mensaje a través de la red y luego, transferir el mensaje hacia arriba, a través de las capas sucesivas del software de protocolo en la maquina receptora.

En la practica, el software es mucho más complejo de lo que se muestra en el modelo. Cada capa toma decisiones acerca de lo correcto del mensaje y selecciona una acción apropiada con base en el tipo de mensaje o la dirección de destino. Por ejemplo, una capa en la maquina de recepción debe decidir cuándo tomar un mensaje o enviarlo a otra maquina. Otra capa debe decidir que programa de aplicación deberá recibir el mensaje.

39

DIAGRAMA B

ROPTOCOLO 1 1 PROTOCOLO 2 PROTOCOLO 3

INTERFAZ 2INTERFAZ 1INTERFAZ 3

MODULO IP

MODELO 2

CAPA DE PROTOCOLO DE ALTO NIVEL

CAPA DE PROTOCOLO DE INTERNET

CAPA DE INTERFAZ DE RED

DIAGRAMA A


Para entender la diferencia entre la organización conceptual del software de protocolo y los detalles de implantación, consideremos la comparación de la figura 2 . El diagrama conceptual (A) muestra una capa de Internet entre una capa de protocolo de alto nivel y una capa de interfaz de red. El diagrama realista (B) muestra el hecho de que el software IP puede comunicarse con varios módulos de protocolo de alto nivel y con varias interfaces de red.

Aun cuando un diagrama conceptual de la estratificación por capas no todos los detalles, sirven como ayuda para explicar los conceptos generales. Por ejemplo el modelo 3 muestra las capas del software de protocolo utilizadas por un mensaje que atraviesa tres redes. El diagrama muestra solo la interfaz de red y las capas de protocolo Internet en los ruteadores debido a que sólo estas capas son necesarias para recibir, rutear y enviar los diagramas. Sé en tiende que cualquier maquina conectada hacia dos redes debe tener dos módulos de interfaz de red, aunque el diagrama de estratificación por capas muestra sólo una capa de interfaz de red en cada maquina.

Como se muestra en la figura, el emisor en la maquina original emite un mensaje que la capa del IP coloca en un datagrama y envía a través de la red 1. En las maquinas intermedias el datagrama pasa hacia la capa IP, la cual rutea el datagrama de regreso, nuevamente(hacia una red diferente). Sólo cuando se alcanza la maquina en el destino IP extrae el mensaje y lo pasa hacia arriba, hacia la capa superior del software de protocolos.

40

EMISOR

OTRAS...

CAPA IP

INTERFAZ

CAPA IP

INTERFAZ

CAPA IP

INTERFAZ

RECEPTOR

OTRA...

CAPA IP

INTERFAZ

RED 1 RED 2 RED 3


Funcionalidad de las capas

Una vez que se toma la decisión de subdividir los problemas de comunicación en cuatro subproblemas y organizar el software de protocolo en módulos, de manera que cada uno maneja un problema, surge la pregunta. “¿Qué tipo de funciones debe instalar en cada modulo?”. La pregunta no es fácil de responder por varias razones. En primer lugar, un grupo de objetivos y condiciones determinan un problema de comunicación en particular, es posible elegir una organización que optimice un software de protocolos para ese problema. Segundo, incluso cuando se consideran los servicios generales al nivel de red, como un transporte confiable es posible seleccionar entre distintas maneras de resolver el problema. Tercero, el diseño de una arquitectura de red y la organización del software de protocolo esta interrelacionado; no se puede diseñar a uno sin considera al otro.

Modelo de referencia iso de 7 capas

Existen dos modelos dominantes sobre la estratificación por capas de protocolo. La primera, basada en el trabajo realizado por la International Organization for Standardization (Organización para la Estandarización o ISO, por sus siglas en inglés ), conocida como Referencia Model of Open System Interconnection Modelo de referencia de interconexión de sistemas abiertos) de ISO, denominada frecuentemente modelo ISO. El modelo ISO contiene 7 capas conceptuales organizadas como se muestra a continuación:

CAPA FUNCION

41

APLICACION

PRESENTACION

SESION

TRANSPORTE

RED

ENLACE DE DATOS (INTERFAZ DE HARWARE)

CONEXIÓN DE

1

2

3

4

5

6

7


El modelo ISO, elaborado para describir protocolos para una sola red, no contiene un nivel especifico para el ruteo en el enlace de redes, como sucede con el protocolo TCP/IP.

Función Tcp/ip

Una red TCP/IP transfiere datos mediante el ensamblaje de bloques de datos en paquetes, cada paquete comienza con una cabecera que contiene información de control; tal como la dirección del destino, seguido de los datos. Cuando se envía un archivo por la red TCP/IP, su contenido se envía utilizando una serie de paquetes diferentes. El Internet protocol (IP), un protocolo de la capa de red, permite a las aplicaciones ejecutarse transparentemente sobre redes interconectadas. Cuando se utiliza IP, no es necesario conocer que hardware se utiliza, por tanto ésta corre en una red de área local.

El Transmissión Control Protocol (TCP); un protocolo de la capa de transporte, asegura que los datos sean entregados, que lo que se recibe, sea lo que se pretendía enviar y que los paquetes que sean recibidos en el orden en que fueron enviados. TCP terminará una conexión si ocurre un error que haga la transmisión fiable imposible.

Administración tcp/ipTCP/IP es una de las redes más comunes utilizadas para conectar computadoras con

sistema UNIX. Las utilidades de red TCP/IP forman parte de la versión 4, muchas facilidades de red como un sistema UUCP, el sistema de correo, RFS y NFS, pueden utilizar una red TCP/CP para comunicarse con otras máquinas.

Para que la red TCP/IP esté activa y funcionado será necesario:

Obtener una dirección Internet.

Instalar las utilidades Internet en el sistema

Configurar la red para TCP/IP

Configurar los guiones de arranque TCP/IP

Identificar otras máquinas ante el sistema

Configurar la base de datos del o y ente de STREAMS

Comenzar a ejecutar TCP/IP.

42


¿QUÉ ES INTERNET?

Internet es una red de computadoras que utiliza convenciones comunes a la hora de nombrar y direccionar sistemas. Es una colecciona de redes independientes interconectadas; no hay nadie que sea dueño o active Internet al completo.

Las computadoras que componen Internet trabajan en UNIX, el sistema operativo Macintosh, Windows 95 y muchos otros. Utilizando TCP/IP y los protocolos veremos dos servicios de red:

Servicios de Internet a nivel de aplicación

Servicios de Internet a nivel de red

SERVICIOS DE INTERNET A NIVEL DE APLICACIÓN:

Desde el punto de vista de un usuario, una red de redes TCP/IP aparece como un grupo de programas de aplicación que utilizan la red para llevar a cabo tareas útiles de comunicación. Utilizamos el término interoperabilidad para referirnos a la habilidad que tienen diversos sistemas de computación para cooperar en la resolución de problemas computacionales. Los programas de aplicación de Internet muestran un alto grado de interoperabilidad. La mayoría de usuarios que accesan a Internet lo hacen al correr programas de aplicación sin entender la tecnología TCP/IP, la estructura de la red de redes subyacente o incluso sin entender el camino que siguen los datos hacia su destino. Sólo los programadores que crean los programas de aplicación de red necesitan ver a la red de redes como una red, así como entender parte de la tecnología. Los servicios de aplicación de Internet más populares y difundidos incluyen:

Correo electrónico. El correo electrónico permite que un usuario componga memorandos y los envíe a individuos o grupos. Otra parte de la aplicación de correo permite que un usuario lea los memorandos que ha recibido. El correo electrónico ha sido tan exitoso que muchos usuarios de Internet depende de él para su correspondencia normal de negocios. Aunque existen muchos sistemas de correo electrónico, al utilizar TCP/IP se logra que la entrega sea más confiable debido a que non se basa en compradoras intermedias para distribuir los mensajes de correo. Un sistema de entrega de correo TCP/IP opera al hacer que la máquina del transmisor contacte directamente la máquina del receptor. Por lo tanto, el transmisor sabe que, una vez que el mensaje salga de su máquina local, se habrá recibido de manera exitosa en el sitio de destino.

43


Transferencia de archivos. Aunque los usuarios algunas veces transfieren archivos por medio del correo electrónico, el correo está diseñado principalmente para mensajes cortos de texto. Los protocolos TCP/IP incluyen un programa de aplicación para transferencia de archivos, el cual permite que lo usuarios envíen o reciban archivos arbitrariamente grandes de programas o de datos. Por ejemplo, al utilizar el programa de transferencia de archivos, se puede copiar de una máquina a otra una gran base de datos que contenga imágenes de satélite, un programa escrito en Pascal o C++, o un diccionario del idioma inglés. El sistema proporciona una manera de verificar que los usuarios cuenten con autorización o, incluso, de impedir el acceso. Como el correo, la transferencia de archivos a través de una red de redes TCP/IP es confiable debido a que las dos máquinas comprendidas se comunican de manera directa, sin tener que confiar en máquinas intermedias para hacer copias del archivo a lo largo del camino.

Acceso remoto. El acceso remoto permite que un usuario que esté frente a una computadora se conecte a una máquina remota y establezca una sesión interactiva. El acceso remoto hace aparecer una ventana en la pantalla del usuario, la cual se conecta directamente con la máquina remota al enviar cada golpe de tecla desde el teclado del usuario a una máquina remota y muestra en la ventana del usuario cada carácter que la computadora remota lo genere. Cuando termina la sesión de acceso remoto, la aplicación regresa al usuario a su sistema local.

SERVICIOS DE INTERNET A NIVEL DE RED

Un programador que crea programas de aplicación que utilizan protocolos TCP/IP tiene una visión totalmente diferente de una red de redes, con respecto a la visión que tiene un usuario que únicamente ejecuta aplicaciones como el correo electrónico. En el nivel de red, una red de redes proporciona dos grandes tipos de servicios que todos los programas de aplicación utilizan. Aunque no es importante en este momento entender los detalles de estos servicios, no se deben omitir del panorama general del TCP/IP:

Servicio sin conexión de entrega de paquetes. La entrega sin conexión es una abstracción del servicio que la mayoría de las redes de conmutación de paquetes ofrece. Simplemente significa que una red de redes TCP/IP rutea mensajes pequeños de una máquina a otra, basándose en la información de dirección que contiene cada mensaje. Debido a que el servicio sin conexión rutea cada paquete por separado, no garantiza una entrega confiable y en orden. Como por lo general se introduce directamente en el hardware subyacente, el servicio sin conexión es muy eficiente.

44


Servicio de transporte de flujo confiable. La mayor parte de las aplicaciones necesitan mucho más que sólo la entrega de paquetes, debido a que requieren que el software de comunicaciones se recupere de manera automática de los errores de transmisión, paquetes perdidos o fallas de conmutadores intermedios a lo largo del camino entre el transmisor y el receptor. El servicio de transporte confiable resuelve dichos problemas. Permite que una aplicación en una computadora establezca una “conexión” con una aplicación en otra computadora, para después enviar un gran volumen de datos a través de la conexión como si fuera perramente y directa del hardware.

Muchas redes proporcionan servicios básicos similares a los servicios TCP/IP, pero existen unas características principales que los distingue de los otros servicios:

Independencia de la tecnología de red. Ya que el TCP/IP está basado en una tecnología convencional de conmutación de paquetes, es independiente de cualquier marca de hardware en particular. La Internet global incluye una variedad de tecnologías de red que van de redes diseñadas para operar dentro de un solo edificio a las diseñadas para abarcar grandes distancias. Los protocolos TCP/IP definen la unidad de transmisión de datos, llamada datagrama, y especifican cómo transmitir los datagramas en una red en particular.

Interconexión universal. Una red de redes TCP/IP permite que se comunique cualquier par de computadoras conectadas a ella. Cada computadora tiene asignada una dirección reconocida de manera universal dentro de la red de redes. Cada datagrama lleva en su interior las direcciones de destino para tomar decisiones de ruteo.

Acuses de recibo puntoapunto. Los protocolos TCP/IP de una red de redes proporcionan acuses de recibo entre la fuente y el último destino en vez de proporcionarlos entre máquinas sucesivas a lo largo del camino, aún cuando las dos máquinas no estén conectadas a la misma red física.

Estándares de protocolo de aplicación. Además de los servicios básicos de nivel de transporte (como las conexiones de flujo confiable), los protocolos TCP/IP incluyen estándares para muchas aplicaciones comunes, incluyendo correo electrónico, transferencia de archivos y acceso remoto. Por lo tanto, cuando se diseñan programas de aplicación que utilizan el TCP/IP, los programadores a menudo se encuentran con que el software ya existente proporciona los servicios de comunicación que necesitan.

Protocolo UDP

El protocolo UDP (User Datagram Protocol, protocolo de datagrama de usuario) proporciona una comunicación muy sencilla entre las aplicaciones de dos ordenadores. Al igual que el protocolo IP, UDP es:

45


• No orientado a conexión . No se establece una conexión previa con el otro extremo para transmitir un mensaje UDP. Los mensajes se envían sin más y éstos pueden duplicarse o llegar desordenados al destino.

• No fiable . Los mensajes UDP se pueden perder o llegar dañados.

UDP utiliza el protocolo IP para transportar sus mensajes. Como vemos, no añade ninguna mejora en la calidad de la transferencia; aunque sí incorpora los puertos origen y destino en su formato de mensaje. Las aplicaciones (y no el protocolo UDP) deberán programarse teniendo en cuenta que la información puede no llegar de forma correcta.

Encabezado UDP

Área de datos UDP

Encabezado del datagrama

Área de datos del datagrama IP

Encabezado de la trama

Área de datos de la trama Final de la trama

Formato del mensaje UDP

0 10 20 30

0 1 2 3 4 5 6 7 8 9 0 1 2 3 3 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Puerto UDP origen Puerto UDP destino

Longitud mensaje UDP Suma verificación UDP

Datos

...

• Puerto UDP de origen (16 bits, opcional). Número de puerto de la máquina origen.

• Puerto UDP de destino (16 bits). Número de puerto de la máquina destino.

• Longitud del mensaje UDP (16 bits). Especifica la longitud medida en bytes del mensaje UDP incluyendo la cabecera. La longitud mínima es de 8 bytes.

46


• Suma de verificación UDP (16 bits, opcional). Suma de comprobación de errores del mensaje. Para su cálculo se utiliza una pseudocabecera que también incluye las direcciones IP origen y destino. Para conocer estos datos, el protocolo UDP debe interactuar con el protocolo IP.

• Datos. Aquí viajan los datos que se envían las aplicaciones. Los mismos datos que envía la aplicación origen son recibidos por la aplicación destino después de atravesar toda la Red de redes.

Nombres de dominio (DNS)

Generalmente nosotros no trabajamos con direcciones IP sino con nombres de dominio del estilo de www.saulo.net o msnews.microsoft.com. Para que esto pueda ser posible es necesario un proceso previo de conversión de nombres de dominio a direcciones IP, ya que el protocolo IP requiere direcciones IP al enviar sus datagramas. Este proceso se conoce como resolución de nombres.

Métodos estándar de resolución de nombres

A continuación se comentan brevemente los distintos métodos de resolución de nombres que utiliza Microsoft Windows para traducir un nombre de dominio a dirección IP. Estos métodos son aplicables a las utilidades TCP/IP que proporciona Windows (Ping, Tracert...) y son distintos a los utilizados desde Entorno de Red.

Método de resolución Descripción1. Local host name Nombre de host configurado para la máquina (Entorno de Red, TCP/IP,

configuración DNS)2. Fichero HOSTS Fichero de texto situado en el directorio de Windows que contiene una

traducción de nombres de dominio en direcciones IP.3. Servidor DNS Servidor que mantiene una base de datos de direcciones IP y nombres

de dominio4. Servidor de nombres NetBIOS

Servidor que mantiene una base de datos de direcciones IP y nombres NetBIOS. Los nombres NetBIOS son los que vemos desde Entorno de Red y no tienen porqué coincidir con los nombres de dominio

5. Local Broadcast Broadcasting a la subred local para la resolución del nombre NetBIOS6. Fichero LMHOSTS Fichero de texto situado en el directorio de Windows que contiene una

traducción de nombres NetBIOS en direcciones IP

Cada vez que escribimos un nombre de dominio en una utilidad TCP/IP, por ejemplo:

C:\>ping www.ibm.com

47


se van utilizando cada uno de los métodos descritos desde el primero al último hasta que se consiga resolver el nombre. Si después de los 6 métodos no se ha encontrado ninguna coincidencia, se producirá un error.

El fichero HOSTS proporciona un ejemplo muy sencillo de resolución de nombres:

127.0.0.1 localhost192.168.0.69 servidor129.168.0.1 router

Necesidad del DNS

En los orígenes de Internet, cuando sólo había unos cientos de ordenadores conectados, la tabla con los nombres de dominio y direcciones IP se encontraba almacenada en un único ordenador con el nombre de HOSTS.TXT. El resto de ordenadores debían consultarle a éste cada vez que tenían que resolver un nombre. Este fichero contenía una estructura plana de nombres, tal como hemos visto en el ejemplo anterior y funcionaba bien ya que la lista sólo se actualizaba una o dos veces por semana.

Sin embargo, a medida que se fueron conectando más ordenadores a la red comenzaron los problemas: el fichero HOSTS.TXT comenzó a ser demasiado extenso, el mantenimiento se hizo difícil ya que requería más de una actualización diaria y el tráfico de la red hacia este ordenador llegó a saturarla.

Es por ello que fue necesario diseñar un nuevo sistema de resolución de nombres que distribuyese el trabajo entre distintos servidores. Se ideó un sistema jerárquico de resolución conocido como DNS (Domain Name System, sistema de resolución de nombres).

Componentes del DNS

Para su funcionamiento, el DNS utiliza tres componentes principales:

• Clientes DNS (resolvers). Los clientes DNS envían las peticiones de resolución de nombres a un servidor DNS. Las peticiones de nombres son preguntas de la forma: ¿Qué dirección IP le corresponde al nombre nombre.dominio?

• Servidores DNS (name servers). Los servidores DNS contestan a las peticiones de los clientes consultando su base de datos. Si no disponen de la dirección solicitada pueden reenviar la petición a otro servidor.

• Espacio de nombres de dominio (domain name space). Se trata de una base de datos distribuida entre distintos servidores.

48


Espacio de nombres de dominio

El espacio de nombres de dominio es una estructura jerárquica con forma de árbol que clasifica los distintos dominios en niveles. A continuación se muestra una pequeña parte del espacio de nombres de dominio de Internet:

El punto más alto de la jerarquía es el dominio raíz. Los dominios de primer nivel (es, edu, com...) parten del dominio raíz y los dominios de segundo nivel (upm, ucm, microsoft...), de un dominio de primer nivel; y así sucesivamente. Cada uno de los dominios puede contener tanto hosts como más subdominios.

Un nombre de dominio es una secuencia de nombres separados por el carácter delimitador punto. Por ejemplo, www.fi.upm.es. Esta máquina pertenece al dominio fi (Facultad de Informática) que a su vez pertenece al dominio upm (Universidad Politécnica de Madrid) y éste a su vez, al dominio es (España).

Generalmente cada uno de los dominios es gestionado por un servidor distinto; es decir, tendremos un servidor para el dominio aq.upm.es (Arquitectura), otro para op.upm.es (Obras Públicas) y así sucesivamente.

Los dominios de primer nivel (TopLevel Domains) han sido clasificados tanto en función de su estructura organizativa como geográficamente. Ejemplos:

En función de su estructura organizativa:

Nombre de dominio Significadocom organizaciones comerciales

netredesorgotras organizacioneseduinstituciones educativas y universidadesgov organizaciones gubernamentalesmil organizaciones militares

49


Geográficamente:

Nombre de dominioSignificadoesEspañatwTaiwánfrFranciatvTuvalu

Zonas de autoridad

Una zona de autoridad es la porción del espacio de nombres de dominio de la que es responsable un determinado servidor DNS. La zona de autoridad de estos servidores abarca al menos un dominio y también pueden incluir subdominios; aunque generalmente los servidores de un dominio delegan sus subdominios en otros servidores.

Tipos de servidores DNS

Dependiendo de la configuración del servidor, éste puede desempeñar distintos papeles:

• Servidores primarios (primary name servers). Estos servidores almacenan la información de su zona en una base de datos local. Son los responsables de mantener la información actualizada y cualquier cambio debe ser notificado a este servidor.

• Servidores secundarios (secundary name servers). Son aquellos que obtienen los datos de su zona desde otro servidor que tenga autoridad para esa zona. El proceso de copia de la información se denomina transferencia de zona.

• Servidores maestros (master name servers). Los servidores maestros son los que transfieren las zonas a los servidores secundarios. Cuando un servidor secundario arranca busca un servidor maestro y realiza la transferencia de zona. Un servidor maestro para una zona puede ser a la vez un servidor primario o secundario de esa zona. Estos servidores extraen la información desde el servidor primario de la zona. Así se evita que los servidores secundarios sobrecargen al servidor primario con transferencias de zonas.

• Servidores locales (cachingonly servers). Los servidores locales no tienen autoridad sobre ningún dominio: se limitan a contactar con otros servidores para resolver las peticiones de los clientes DNS. Estos servidores mantienen una memoria caché con las últimas preguntas contestadas. Cada vez que un cliente DNS le formula una pregunta, primero consulta en su memoria caché. Si encuentra la dirección IP solicitada, se la devuelve al cliente; si no, consulta a otros servidores, apunta la respuesta en su memoria caché y le comunica la respuesta al cliente.

50


Los servidores secundarios son importantes por varios motivos. En primer lugar, por seguridad debido a que la información se mantiene de forma redundante en varios servidores a la vez. Si un servidor tiene problemas, la información se podrá recuperar desde otro. Y en segundo lugar, por velocidad porque evita la sobrecarga del servidor principal distribuyendo el trabajo entre distintos servidores situados estratégicamente (por zonas geográficas, por ejemplo).

Resolución de nombres de dominio

La resolución de un nombre de dominio es la traducción del nombre a su correspondiente dirección IP. Para este proceso de traducción los resolvers pueden formular dos tipos de preguntas (recursivas e iterativas).

• Preguntas recursivas. Si un cliente formula una pregunta recursiva a un servidor DNS, éste debe intentar por todos los medios resolverla aunque para ello tenga que preguntar a otros servidores.

• Preguntas iterativas. Si, en cambio, el cliente formula una pregunta iterativa a un servidor DNS, este servidor devolverá o bien la dirección IP si la conoce o si no, la dirección de otro servidor que sea capaz de resolver el nombre.

Veamos un ejemplo: Estamos trabajando con Internet Explorer y escribimos en la barra de dirección: www.ibm.com. En primer lugar, el navegador tiene que resolver el nombre de dominio a una dirección IP. Después podrá comunicarse con la correspondiente dirección IP, abrir una conexión TCP con el servidor y mostrar en pantalla la página principal de IBM. La siguiente gráfica muestra el esquema de resolución:

1. Nuestro ordenador (cliente DNS) formula una pregunta recursiva a nuestro servidor DNS local (generalmente el proveedor de Internet).

51


2. El servidor local es el responsable de resolver la pregunta, aunque para ello tenga que reenviar la pregunta a otros servidores. Suponemos que no conoce la dirección IP asociada a www.ibm.com; entonces formulará una pregunta iterativa al servidor del dominio raíz.

3. El servidor del dominio raíz no conoce la dirección IP solicitada, pero devuelve la dirección del servidor del dominio com.

4. El servidor local reenvía la pregunta iterativa al servidor del dominio com.

5. El servidor del dominio com tampoco conoce la dirección IP preguntada, aunque sí conoce la dirección del servidor del dominio ibm.com, por lo que devuelve esta dirección.

6. El servidor local vuelve a reenvíar la pregunta iterativa al servidor del dominio ibm.com.

7. El servidor del dominio ibm.com conoce la dirección IP de www.ibm.com y devuelve esta dirección al servidor local.

8. El servidor local por fin ha encontrado la respuesta y se la reenvía a nuestro ordenador.

52


COMANDOS TCP/IP

TCP/IP incluye dos grupos de comandos utilizados para suministrar servicios de red:

Los comandos remotos BERKELEY

Los comandos DARPA

Los comandos remotos BERKELEY, que fueron desarrollados en la Universidad Berkeley (California), incluyen órdenes para comunicaciones entre sistemas operativos UNIX, como copia remota de archivos, conexión remota, ejecución de shell remoto, etc.

Permiten utilizar recursos con otros hosts, pudiendo tratar distintas redes como si fueran una sola.

En la versión 4 para UNIX Sistema V, se pueden distinguir los siguientes comandos más comunes:

RCP Realiza una copia de archivos al mismo o a otro servidor

RLOGINGLRLOGINVT Se utiliza para hacer una conexión al mismo o a otro servidor

REXECRSH Permite ejecutar comandos del sistema operativo en El mismo o enotro servidor.

Los comandos DARPA incluyen facilidades para emulación de terminales, transferencia de archivos, correo y obtención de información sobre usuarios. Pueden ser utilizadas kpara comunicación con computadores que ejecutan distintos sistemas operativos.

En la versión 2.05 para DOS, dependiendo de las funciones que realizan, se pueden distinguir los siguientes grupos de comandos:

Kernel PC/TCP y herramientas asociadas

Se utilizan para cargar el núcleo TCP/IP en la memoria del computador.

BOOTP Asigna la dirección IP de la estación de trabajo

INET Descarga el núcleo PC/TCP de la memoria y/o realiza estadísticas de red

53


KERNEL Carga el núcleo TCP/IP en la memoria y lo deja residente

Configuración de la redPermiten configurar TCP/IP con determinados parámetros.

IFCONFIG Configura el hardware para TCP/IP

IPCONFIG Configura el software TCP/IP y la direcci6n IP

Transferencia de archivos Se utilizan para transferir archivos entre distintos computadores.

DDAT'ES Muestra las fechas y horas guardadas en un archivo creado con el comando TAR

FTP Transfiere archivos entre una estación de trabajo y un servidor (puerto 21)

FRPSRV Convierte una estación de trabajo en un servidorFTP

PASSWD Se utiliza para poner contraseñas en las estaciones de trabajo a los usuarios para poder utilizar él comando FTPSRV

RMT Permite realizar copia de archivos en una unidad de cinta

TAR Realiza una copia de archivos creando un único archivo de

BACKUP

TFTP Transfiere archivos entre una estación de trabajo un servidor o a otra estación de trabajo sin necesidad de validar al usuario

54


Impresión Permiten el control de la impresión en las impresoras conectadas al servidor.

DOPREDIR Imprime un trabajo de impresión que aún no ha sido impreso

IPRINT Envía un texto o un archivo a un servidor de impresoras de imagen

LPQ Indica el estado de la cola de impresión indicada

LPR Envía un texto o un archivo a una impresora local o de red.

LPRM Elimina trabajos pendientes de la cola de impresión

ONPREDIR Realiza tareas de configuración para el comando PREDIR

PREDIR Carga o descarga el programa que permite la impresión remota y lo deja residente.

PRINIT Se usa con los comandos PREDIR y ONPREDIR

PRSTART Indica a la estación de trabajo remota que imprima un archivo usando la configuración por defecto

Conexión a servidores Permiten la conexión de los computadores a servidores de nuestra red.

SUPDUP Permite conectarse a otro servidor de la red

TELNET TN Es el método normal de conectarse a un servidor de la red

Información sobre los usuarios Muestran información sobre los usuarios conectados a la red.

FINGER Muestra información sobre un usuario conectado a otra estación de trabajo

NICNAME Muestra información sobre un usuario o sobre un servidor solicitada al centro de informaci6n de redes

WHOIS Muestra información sobre un usuario registrado que esté conectado a otra estación de trabajo

55


Envío y recepción de correo Estos comandos permiten el envío y/o recepción de correo entre los usuarios de la red.

MAIL Permite enviar y recibir correo en la red

PCMAILPermite leer correo. Se ha de usar con el comando VMAILPOP2 POP3 Se utiliza para leer correo. Se han de usar con VMAIL Y

SMTP

SMTP Se utiliza para enviar correo en la red

SMTPSRV Permite leer el correo recibido

VMAIL Es un comando que muestra una pantalla preparada para leer el correo recibido. Se utiliza en conjunción con los comandos PCMAIL, POP2 0 POP3

Chequeo de la red Permiten chequear la red cuando aparecen problemas de comunicaciones.

HOST Indica el nombre y la dirección IP de una estación de trabajo determinada

PING Envía una Llamada a una estación de trabajo e informa si se puede establecer conexión o no con ella

SETCLOCK Muestra la fecha y la hora que tiene la red

56

manual tcp ip

Documents

datagrama se

igrp protocolo

debeevaluarseel campo

si se vence y aun

software que implementa

sus fragmentos se

llama fragmento

mide en bytes