Intercomunicacion y seguridad en redes

Presentación
El objetivo de este curso es el dar a comprender al estudiante los principios de la
interconectividad y seguridad en las redes de redes.
El panorama de las redes ha cambiado radicalmente desde la tercera edición. A
mediados de la década de 1990 existían varios tipos de LANs y WANs, junto con pilas
de múltiples protocolos.
Para el 2003, la única LAN alámbrica de amplio uso tal vez sea Ethernet y
prácticamente todas las WANs estarían en Internet. En consecuencia, se habrá
eliminado una gran cantidad de material referente a estas antiguas redes.
Sin embargo, también abundan los nuevos desarrollos. Lo más importante es el gran
aumento de redes inalámbricas, como la 802.11, los ciclos locales inalámbricos, las
redes celulares 2G y 3G, Bluetooth, WAP (protocolo de aplicaciones inalámbricas), el i-
mode y otros. De acuerdo con esto, se ha agregado una gran cantidad de material a las
redes inalámbricas. Otro tema importante y novedoso es la seguridad, por lo que se ha
agregado todo un capítulo al respecto.
Dejar un comentario
Archivado bajo Uncategorized
· 10:26 am
Unidad 1. Interconectividad
1.1 Concepto de Servicio Universal.
El origen del servicio universal se remonta a 1907, cuando Theodore Vail, presidente de
AT&T, propuso al gobierno de Estados Unidos que el sector de las telecomunicaciones
debía organizarse como un monopolio para evitar la discontinuidad de la red. Vail
denominó a esto ―one system, one policy, universal service‖. Este principio se acabó
formalizando en 1913 en el Kingsbury Commitment, que permitió a AT&T adquirir
diferentes operadores locales e iniciar la interconexión de las zonas en las que tenía
presencia. Fue así como empezó el proceso de universalización de las
telecomunicaciones.
En muchos países, las primeras grandes empresas de telecomunicaciones fueron
monopolios públicos, de manera que la universalización se logró a través de la acción
directa del Estado. En las últimas décadas del siglo XX, el proceso general de
liberalización de las industrias de red ha supuesto grandes retos para los reguladores.
Mantener las obligaciones del servicio universal bajo un régimen competitivo es una
tarea difícil.
1.2 Interconectividad.

La Interconectividad (Internetworking) puede ser definida como: ―Comunicación entre
dos o más redes‖ (IBM).
―Proceso de comunicación el cual ocurre entre dos o más redes que están conectadas
entre sí de alguna manera‖.
1.3 Arquitectura de las Interredes.
El primer objetivo de diseño de TCP/IP fue construir una interconexión de redes que
proporcionen servicios de comunicación universal: una interred o internet. Cada red
física tiene su propio interfaz de comunicación dependiente de la tecnología en forma de
interfaz de programación que proporciona funciones de comunicación básica
(primitivas). Los servicios de comunicación se proporcionan mediante software que se
ejecuta entre la red física y las aplicaciones de usuario y que proporcionan una interfaz
para estas aplicaciones, independiente de la red física subyacente. La arquitectura de las
redes físicas es transparente al usuario.
El segundo objetivo es interconectar diferentes redes físicas para formar lo que
aparentemente es una red grande para el usuario. Tal conjunto de redes interconectadas
se denomina una interred o internet.
Para ser capaz de interconectar dos redes, se necesita un ordenador que se conecte a
ambas redes y que puede enviar paquetes desde una red a la otra. El término router IP
también se usa porque la función de encaminamiento es parte de la capa de IP de la
familia de protocolos TCP/IP.
La figura siguiente muestra dos ejemplos de interredes:
Las propiedades básicas de un router son:
Desde el punto de vista de la red, un router es un host normal.
Desde el punto de vista del usuario, los routers son invisibles. El usuario ve sólo
una gran interred.
Para ser capaces de identificar un host en la interred, a cada host se le asigna una
dirección, la dirección IP. Cuando un host tiene múltiples adaptadores de red, cada
adaptador tiene una dirección IP aparte. La dirección IP consta de dos partes:
dirección IP = <número de red><número de host>

Parte del número de red de la dirección IP la asigna una autoridad central y es único en
toda Internet. La autoridad para asignar parte del número de host de la dirección IP
reside con la organización que controla la red identificada por el número de red. El
esquema de direccionamiento se describe detalladamente en Direccionamiento.
1.4 Protocolos de Interconectividad.
Aunque se han adaptado muchos protocolos para usarse en intercedes, una familia
destaca como la más usada en la interconectividad. Formalmente, se conoce como la
familia de protocolos TCP/IP de Internet; casi todos los expertos en informática la
llaman TCP/IP.
TCP/IP fue la primera familia de protocolos desarrollado para usarse en intercedes. El
trabajo sobre TCP/IP comenzó en los años 70‘s casi al mismo tiempo que se
desarrollaban las LAN. El ejercito de los EUA financio gran parte del desarrollo del
TCP/IP y la ínter conectividad por medio de la Agencia de Investigación Avanzada de
Proyectos (ARPA). Las instituciones militares fueron las primeras organizaciones que
tuvieron varias redes. A mediados de los 80‘s, la Fundación Nacional de Ciencias y
otras dependencias gubernamentales de los Estados Unidos financiaron el desarrollo de
TCP/IP y de una interred grande para probar los protocolos.
Dejar un comentario
· 3:41 am
UNIDAD 2: Protocolo TCP/IP
TCP/IP es el protocolo común utilizado por todos los ordenadores conectados a Internet,
de manera que éstos puedan comunicarse entre sí. Hay que tener en cuenta que en
Internet se encuentran conectados ordenadores de clases muy diferentes y con hardware
y software incompatibles en muchos casos, además de todos los medios y formas
posibles de conexión. Aquí se encuentra una de las grandes ventajas del TCP/IP, pues
este protocolo se encargará de que la comunicación entre todos sea posible. TCP/IP es
compatible con cualquier sistema operativo y con cualquier tipo de hardware.
TCP/IP no es un único protocolo, sino que es en realidad lo que se conoce con este
nombre es un conjunto de protocolos que cubren los distintos niveles del modelo OSI.
Los dos protocolos más importantes son el TCP (Transmission Control Protocol) y el IP
(Internet Protocol), que son los que dan nombre al conjunto.
2.1 Servicios de TCP/IP
DNS
En el grupo de protocolos TCP-IP se encuentran los protocolos de resolución de
nombres por direcciones IP. Estos protocolos permiten a las aplicaciones tener acceso a
los servicios de un computador a través del uso de un nombre. Para ello debe existir un

mecanismo que permita la resolución y asociación de una dirección IP por un nombre.
El mecanismo de asociación consiste en una base de datos donde se encuentran las
asociaciones de una dirección IP con su nombre respectivo. Y el mecanismo de
resolución consiste en identificar cual es la dirección IP asociada a un nombre. De esta
manera los computadores de la red pueden ser accesados a través de un nombre en vez
de su dirección IP.
En los comienzos de la red Internet la resolución de nombres por números IP se
realizaba a través de un archivo de texto llamado hosts. Este archivo de texto contenía
toda las direcciones IP asociadas al nombre asignado a cada computador. A medida que
la red Internet fue creciendo este método de resolución de nombre por números IP fue
presentando problemas debido a que el archivo hosts era administrado por el
administrador de cada red, de esta manera no se podía garantizar que un administrador
no asignará el mismo nombre a máquinas distintas ubicadas en redes distintas. Esto trae
como consecuencia la colisión de nombres e inconsistencia del archivo hosts a lo largo
de una red en crecimiento.
El formato de este archivo de texto es el siguiente:
user@pc-1:~$ cat /etc/hosts
127.0.0.1 localhost pc-1
192.168.2.1 pc-2
Con el fin de resolver los problemas explicados anteriormente se desarrolló el protocolo
de Sistema de nombres de dominios ―DNS Domain Name System‖. Este protocolo es
una base de datos distribuida que permite un control local sobre los segmentos de la
base de datos en general, logrando que cada segmento esté disponible a lo largo de toda
la red Internet. El sistema de nombres de dominios utiliza un esquema cliente servidor.
El protocolo DNS está compuesto por dos programas uno llamado servidor de nombres
de dominios y otro llamado resolvers. Los servidores de nombres de dominios contienen
la base de datos de un segmento y dicha base de datos es accesada por los clientes a
través de un programa conocido como resolvers. Los resolvers son rutinas utilizadas
para tener acceso a la base de datos ubicada en los servidores de nombres de dominios
con el fin de resolver la búsqueda de una dirección IP asociada a un nombre.

Estructura gráfica de una base de datos DNS
Protocolo DNS
En la imagen podemos observar la estructura gráfica de una base de datos DNS donde
cada nodo es un nombre de dominio, Todos los nombres de dominios nacen a partir del
dominio raíz, el cual se denota con un punto. A su vez cada uno de estos nombres de
dominio puede sub-dividirse. Por ejemplo, el dominio .org. incluye a dos nombres de
dominio caida y kernel. Cada uno de estos nombres de dominio tienen dos nombres de
dominio llamados http://www.caida.org. y http://ftp.caida.org y http://www.kernel.org.
y http://ftp.kernel.org.. Esto implica que el nombre de dominio www asignado a dos
computadores ―www.caida.org. y http://www.kernel.org.‖; gozan de un nombre de
dominio único. Cada uno de estos nombres de dominio son nombres de dominio
completamente calificados ―FQDN, Full Qualified Domain Name‖. De esta manera dos
computadoras pueden tener el mismo nombre sí y sólo sí pertenecen a zonas distintas.
Una zona representa las partes contiguas del árbol del dominio para el cual un servidor
de nombres contiene la información completa y es autoridad del dominio. En la imagen
podemos apreciar dos zonas Caida.org. y Kernel.org.. Los servidores de dominio de
cada zona contienen en sus bases de datos la dirección IP asociada al nombre de
dominio.
El servidor de nombres de una zona puede delegar la responsabilidad del sistema de
nombres de dominios a otro servidor de nombres de dominio con el fin de descentralizar
la base de datos. Tal es el ejemplo de los servidores de nombres ―.‖ raíz presentados en
la imagen. Estos servidores de nombres delegan sus zonas a los servidores de nombres
del dominio org..
Como cada computadora está asociada a un nombre de dominio completamente
calificado ―FQDN‖ y un FQDN tiene asociado una dirección IP, esto implica que los
servicios ofrecidos por una computadora pueden ser accesados a través de un nombre

completamente calificado. El nombre de un dominio puede tener hasta 63 caracteres de
longitud y puede pertenecer a cualquiera de los 127 niveles posibles. En el protocolo
DNS no existe diferencia entre mayúsculas o minúsculas. Un dominio puede ser una
computadora o puede ser un nodo del cual parten otros dominios.
Un nombre de dominio es un índice dentro de la base de datos DNS. Los nombres
indexados en un dominio son las rutas que conforman el espacio de nombres de
dominio. El nombre completo asociado a una dirección IP es una secuencia de nombres
de dominios asignados desde su nodo hasta el nodo raíz.
El espacio de dominio de la red Internet está dividido básicamente en tres niveles: Nivel
Raíz, Nivel Tope y Nivel secundario. En la imagen podemos observar el nivel
jerárquico de cada uno de estos niveles.
Espacio de dominio de la red Internet
Base de datos del protocolo DNS
Cada servidor de nombres de dominio mantiene una base de datos que sirve para asociar
los nombres de dominios con direcciones IP. Está base de datos se conoce con el
nombre de archivos de la zona. Cada servidor de nombres de dominio también mantiene
una base de datos de resolución inversa. Esta base de datos se conoce con el nombre de
archivos de resolución inversa de la zona.
Ambas bases de datos son manejadas por un servidor de nombres, el cual responde a las
solicitudes hechas por el resolver. El formato de dichas bases de datos son archivos de
texto donde se definen los registros de recurso ―Resource Records RR‖ que sirven para
especificar la relación entre un nombre de dominio y una dirección IP además sirve para
especificar en qué zona del espacio de nombres de dominios el servidor de nombres de
dominios pertenece.

La siguiente tabla presenta los registros de recursos más comunes para la clase IN, es
decir; Internet.
Nombre del
Recurso
Tipo de
Registro
Función
Inicio de autoridad SOA Parámetros que gobiernan la zona
Servidor de
nombres
NS Indentifica el servidor de nombres de una Zona.
Dirección A Asocia un nombre con una direccion IP
Puntero PTR
Asocia una direccion IP con un nombre. Búsqueda
inversa
Oficinas de Correo MX
Indentifica donde deben ser enviados los correos
electrónicos del dominio
Nombre Canonico CNAME Define un alias para un nombre ya definido
Informacion de
estación
HINFO
Utilizado para definir el hardware y/o Sistema
operativo de un computador
Servicios ofertados WKS Anuncia los servicios
Text TXT Almacena cualquier información
El formato de un registro de recurso es el siguiente:
[nombre] [ttl] IN <tipo de registro><valor>
-. [nombre] es el nombre del objeto referenciado por el registro del recurso. Puede ser
un nombre de estación o un nombre de dominio.
-. [ttl] es el tiempo de vida del registro. Define la cantidad de segundos que la
información sobre este registro puede ser mantenida en la memoria de un servidor de
dominios. Si el ttl es omitido usa el ttl indicado por el recurso definido en la sección
SOA.
-. IN Identifica la clase del registro como clase Internet.
-. <tipo de registro> Identifica el tipo de recurso de acuerdo a la tabla anterior.
-. <valor> es la información específica al tipo de recurso.
FTP
FTP significa File Transfer Protocol, protocolo de transferencia de ficheros. Es un
servicio de Internet que permite transferencia de archivos. Se utiliza en modo cliente-
servidor: conectados a un ordenador remoto (que actúa como servidor y que es un gran
ordenador permanentemente conectado a Internet) nuestro programa (cliente) nos
permite solicitar la transferencia de archivos en cualquiera de las dos direcciones.
El servidor de archivos debe admitir las transferencias de tipo FTP, por lo que deberá
ser un ordenador especialmente preparado para esta tarea. En nuestro ordenador
necesitaremos un programa específico; hay varios muy populares, gratuitos, algunos

incluso en castellano. A nuestro programa le indicaremos en primer lugar cuál es el
servidor que vamos a utilizar.
Algunos servidores solamente admiten conexiones identificadas: el usuario debe iniciar
su conexión mediante una identificación (―login‖) y una clave secreta (―password‖). En
ese caso, y dependiendo del usuario, se podrá acceder a más o menos directorios del
servidor. Muchos servidores de FTP también admiten la posibilidad de hacer una
conexión no identificada, anónima: en tal caso debemos utilizar como identificativo la
palabra ―anonymous‖; es de cortesía utilizar la dirección de correo electrónico como
clave secreta, para que los administradores del servidor puedan llevar una estadística de
los diferentes accesos anónimos.
Típicamente, los programas de FTP muestran en dos ―ventanas‖ los archivos
correspondientes a los directorios elegidos en el disco local y en el servidor. Existen
procedimientos para cambiar el directorio de cualquiera de los dos ordenadores. En el
caso del servidor remoto, es posible que la identificación de la conexión no nos permita
acceder a todos los directorios (esto puede ser así, tanto para las conexiones
identificadas como para las anónimas). Algunos servidores nos permitirán obtener
archivos remotos, pero no nos consentirán el envío de ficheros hacia el servidor.
Típicamente la transferencia se realiza seleccionando en la lista los archivos que se
desean transferir y pulsando en el botón correspondiente para que se inicie la
transferencia. Es posible transferir varios archivos en bloque.
Las transferencias pueden realizarse en dos modos: texto y binario; el primero es
adecuado solo para los archivos de texto (ASCII o ANSI), mientras que el segundo es
válido para todos los ficheros.
Los programas más populares para realizar FTP son conocidos por los siguientes
nombres: CuteFTP y WS_FTP. Se pueden conseguir fácilmente a través del Web y,
lamentablemente, están en inglés.
El sistema FTP está sufriendo una importante devaluación porque la mayoría de las
transferencias pueden efectuarse desde páginas Web y utilizando el programa
navegador, lo cual facilita y simplifica la tarea. Esto solo es válido para transferencias
descendentes (desde el servidor remoto al ordenador local) y en formato ―anónimo‖. El
servicio Web integra perfectamente este modo de FTP, que es el utilizado por la
mayoría de los usuarios.
En cada directorio del servidor suele haber un archivo de texto que explica el contenido
de los otros ficheros y de los subdirectorios. Con los programas más potentes es posible
acceder a este fichero (en una ventana) sin necesidad de guardar una copia en el disco
duro local. Los directorios pueden estar organizados por temas, por sistemas operativos
o por cualquier otro criterio.
El sistema FTP también es usado habitualmente para colocar las páginas Web en los
ordenadores que se dedican a este servicio. Las páginas son ―creadas‖ en el disco duro y
luego son transferidas utilizando el sistema FTP.
DHCP

DHCP (Dynamic Host Configuration Protocol) son las siglas que identifican a un
protocolo empleado para que los hosts (clientes) en una red puedan obtener su
configuración de forma dinámica a través de un servidor del protocolo. Los datos así
obtenidos pueden ser: la dirección IP, la máscara de red, la dirección de broadcast, las
características del DNS, entre otros. El servicio DHCP permite acelerar y facilitar la
configuración de muchos hosts en una red evitando en gran medida los posibles errores
humanos.
Con una función similar a la del DHCP, pero con algunas restricciones, existe el
BOOTP o Internet Bootstrap Protocol, el cual permite también la asignación de la
configuración de red en forma dinámica pero a partir de su definición estática para cada
cliente en una base de datos en el servidor. Esta información a diferencia de como se
hace usualmente con DHCP no puede ser renovada.
Básicamente el servicio DHCP/BOOTP funciona de la siguiente forma. Existe un
programa servidor en un host de la red que escucha las solicitudes de los clientes y que
en su configuración almacena tablas de posibles direcciones IP a otorgar además del
resto de la información. Cuando un cliente requiere del servicio envía una solicitud en
forma de broadcast a través de la red. Todos los servidores alcanzados por la solicitud
responden al cliente con sus respectivas propuestas, este acepta una de ellas
haciéndoselo saber al servidor elegido, el cual le otorga la información requerida. Esta
información se mantiene asociada al cliente mientras este no desactive su interfaz de red
(posiblemente porque se apague la máquina) o no expire el plazo del ―contrato‖ (léase
time). El plazo del ―contrato‖ o renta es el tiempo en que un cliente DHCP mantiene
como propios los datos que le otorgó un servidor. Este se negocia como parte del
protocolo entre el cliente y el servidor. Una vez vencido el plazo del contrato el servidor
puede renovar la información del cliente, fundamentalmente su dirección IP, y asignarle
otra nueva o extender el plazo, manteniendo la misma información. El cliente puede
solicitar también la renovación o liberación de sus Datos.

Representación simplificada del protocolo DHCP.
A continuación se listan los principales mensajes que se intercambian como parte del
protocolo DHCP y para que se emplea cada uno:
DHCPDISCOVER – mensaje de broadcast de un cliente para detectar los servidores.
DHCPOFFER – mensaje de un servidor hacia un cliente con una oferta de
configuración.
DHCPREQUEST – mensaje de un cliente a un servidor para:
a) aceptar la oferta de un servidor determinado y por ende rechazar las otras

b) confirmar la exactitud de la información asignada antes del reinicio del sistema
c) extender el contrato de una dirección IP determinada
DHCPPACK – mensaje del servidor hacia un cliente para enviarle la configuración
asignada excluyendo la dirección IP que ya fue aceptada.
DHCPNAK – mensaje del servidor al cliente para indicar que la dirección que tiene
asignada es incorrecta (por ejemplo, cuando el cliente cambia de subred) o que el
contrato ha expirado.
DHCPDECLINE – mensaje del cliente para el servidor indicando que aún está usando
una dirección determinada.
DHCPRELEASE – mensaje del cliente para el servidor para indicar que renuncia a la
dirección otorgada y cancela lo que queda del contrato establecido anteriormente.
DHCPINFORM – mensaje del cliente para el servidor para pedir sus parámetros de
configuración excluyendo la dirección IP que ya tiene asignada.
Un servidor de DHCP puede identificar a cada cliente a través de dos formas
fundamentales:
La dirección MAC (Media Access Control) de la tarjeta de red del cliente.
Un identificador que le indique el cliente.
Aunque la idea central del servicio DHCP es la dinamicidad de las direcciones IP
asignadas no se excluye la posibilidad de utilizar direcciones fijas para algunos hosts
que por sus características lo requieran, ejemplo de ello son las máquinas proveedoras
de disímiles servicios como el correo electrónico o el DNS. Este tipo de host utilizaría
las ventajas del servicio para obtener el resto de los datos que se pueden proveer
mediante DHCP.
En Linux la implementación del servidor de DHCP y de BOOTP la mantiene la ISC
(Internet Software Consortium). Esta se empaqueta en la distribución Red Hat bajo el
nombre dhcp. Existen además otros dos paquetes asociados a este servicio que
implementan la parte cliente: pump y dhcpcd.
Las ventajas del uso de DHCP son:
a) sólo se configura un servidor para entregar números IP para clientes de red
b) se entregan todos los parámetros básicos de TCP/IP
c) facilidad de configuración
Las desventajas del uso de DHCP son:
a) La seguridad

b) Al entregar números IP dentro de la red, habiendo un DNS, no hay un puente
intermedio entre DNS y DHCP directo. Es decir, hay que agregar las máquinas ―a
mano‖ en el DNS
c) Mayor difusión de paquetes en la red, aunque hoy en día con la velocidad de las
redes no parece demasiado problemático.
WWW
La tecnología World Wide Web surge en la Organización Europea para la Investigación
Nuclear ―CERN‖ cuando Tim Berners-Lee propone la necesidad de implementar un
sistema de gerencia de la información a fin de solucionar la pérdida de información
producida por la dinámica de la organización.
El consorcio W3C fue creado en octubre de 1994 con el fin de estandarizar e
implementar protocolos y especificaciones que promuevan:
-. Nuevas formas de documentación de la información y de comunicación.
-. La implementación de protocolos y especificaciones no propietarias para asegurar la
interoperabilidad entre sistemas operativos.
Desde entonces, la tecnología World Wide Web se ha convertido en el paradigma más
influyente en los actuales sistemas de información.
2.1 Arquitectura de TCP/IP
Ya que dentro de un sistema TCP/IP los datos transmitidos se dividen en pequeños
paquetes, éstos resaltan una serie de características.
La tarea de IP es llevar los datos a granel (los paquetes) de un sitio a otro. Las
computadoras que encuentran las vías para llevar los datos de una red a otra
(denominadas enrutadores) utilizan IP para trasladar los datos. En resumen IP mueve los
paquetes de datos a granel, mientras TCP se encarga del flujo y asegura que los datos
estén correctos.
Las líneas de comunicación se pueden compartir entre varios usuarios. Cualquier tipo de
paquete puede transmitirse al mismo tiempo, y se ordenará y combinará cuando llegue a
su destino. Compare esto con la manera en que se transmite una conversación
telefónica. Una vez que establece una conexión, se reservan algunos circuitos para
usted, que no puede emplear en otra llamada, aun si deja esperando a su interlocutor por
veinte minutos.
Los datos no tienen que enviarse directamente entre dos computadoras. Cada paquete
pasa de computadora en computadora hasta llegar a su destino. Éste, claro está, es el
secreto de cómo se pueden enviar datos y mensajes entre dos computadoras aunque no
estén conectadas directamente entre sí. Lo que realmente sorprende es que sólo se
necesitan algunos segundos para enviar un archivo de buen tamaño de una máquina a
otra, aunque estén separadas por miles de kilómetros y pese a que los datos tienen que
pasar por múltiples computadoras. Una de las razones de la rapidez es que, cuando algo
anda mal, sólo es necesario volver a transmitir un paquete, no todo el mensaje.

Los paquetes no necesitan seguir la misma trayectoria. La red puede llevar cada paquete
de un lugar a otro y usar la conexión más idónea que esté disponible en ese instante. No
todos los paquetes de los mensajes tienen que viajar, necesariamente, por la misma ruta,
ni necesariamente tienen que llegar todos al mismo tiempo.
La flexibilidad del sistema lo hace muy confiable. Si un enlace se pierde, el sistema usa
otro. Cuando usted envía un mensaje, el TCP divide los datos en paquetes, ordena éstos
en secuencia, agrega cierta información para control de errores y después los lanza hacia
fuera, y los distribuye. En el otro extremo, el TCP recibe los paquetes, verifica si hay
errores y los vuelve a combinar para convertirlos en los datos originales. De haber error
en algún punto, el programa TCP destino envía un mensaje solicitando que se vuelvan a
enviar determinados paquetes.
CÓMO FUNCIONA TCP/IP
- IP:
IP a diferencia del protocolo X.25, que está orientado a conexión, es sin conexión. Está
basado en la idea de los datagramas interred, los cuales son transportados
transparentemente, pero no siempre con seguridad, desde el hostal fuente hasta el hostal
destinatario, quizás recorriendo varias redes mientras viaja.
El protocolo IP trabaja de la siguiente manera; la capa de transporte toma los mensajes y
los divide en datagramas, de hasta 64K octetos cada uno. Cada datagrama se transmite a
través de la red interred, posiblemente fragmentándose en unidades más pequeñas,
durante su recorrido normal. Al final, cuando todas las piezas llegan a la máquina
destinataria, la capa de transporte los reensambla para así reconstruir el mensaje
original.
Un datagrama IP consta de una parte de cabecera y una parte de texto. La cabecera tiene
una parte fija de 20 octetos y una parte opcional de longitud variable. En la figura se
muestra el formato de la cabecera. El campo Versión indica a qué versión del protocolo
pertenece cada uno de los datagramas. Mediante la inclusión de la versión en cada
datagrama, no se excluye la posibilidad de modificar los protocolos mientras la red se
encuentre en operación.

El campo Opciones se utiliza para fines de seguridad, encaminamiento fuente, informe
de errores, depuración, sellado de tiempo, así como otro tipo de información. Esto,
básicamente, proporciona un escape para permitir que las versiones subsiguientes de los
protocolos incluyan información que actualmente no está presente en el diseño original.
También, para permitir que los experimentadores trabajen con nuevas ideas y para
evitar, la asignación de bits de cabecera a información que muy rara vez se necesita.
Debido a que la longitud de la cabecera no es constante, un campo de la cabecera, IHL,
permite que se indique la longitud que tiene la cabecera en palabras de 32 bits. El valor
mínimo es de 5. Tamaño 4 bit.
El campo Tipo de servicio le permite al hostal indicarle a la subred el tipo de servicio
que desea. Es posible tener varias combinaciones con respecto a la seguridad y la
velocidad.
Para voz digitalizada, por ejemplo, es más importante la entrega rápida que corregir
errores de transmisión. En tanto que, para la transferencia de archivos, resulta más
importante tener la transmisión fiable que entrega rápida. También, es posible tener
algunas otras combinaciones, desde un tráfico rutinario, hasta una anulación
instantánea. Tamaño 8 bit.
La Longitud total incluye todo lo que se encuentra en el datagrama -tanto la cabecera
como los datos. La máxima longitud es de 65 536 octetos(bytes). Tamaño 16 bit.
El campo Identificación se necesita para permitir que el hostal destinatario determine a
qué datagrama pertenece el fragmento recién llegado. Todos los fragmentos de un
datagrama contienen el mismo valor de identificación. Tamaño 16 bits.
Enseguida viene un bit que no se utiliza, y después dos campos de 1 bit. Las letras DF
quieren decir no fragmentar. Esta es una orden para que las pasarelas no fragmenten el
datagrama, porque el extremo destinatario es incapaz de poner las partes juntas
nuevamente. Por ejemplo, supóngase que se tiene un datagrama que se carga en un
micro pequeño para su ejecución; podría marcarse con DF porque la ROM de micro
espera el programa completo en un datagrama. Si el datagrama no puede pasarse a
través de una red, se deberá encaminar sobre otra red, o bien, desecharse.
Las letras MF significan más fragmentos. Todos los fragmentos, con excepción del
último, deberán tener ese bit puesto. Se utiliza como una verificación doble contra el
campo de Longitud total, con objeto de tener seguridad de que no faltan fragmentos y
que el datagrama entero se reensamble por completo.
El desplazamiento de fragmento indica el lugar del datagrama actual al cual pertenece
este fragmento. En un datagrama, todos los fragmentos, con excepción del último,
deberán ser un múltiplo de 8 octetos, que es la unidad elemental de fragmentación.
Dado que se proporcionan 13 bits, hay un máximo de 8192 fragmentos por datagrama,
dando así una longitud máxima de datagrama de 65 536 octetos, que coinciden con el
campo Longitud total. Tamaño 16 bits.

El campo Tiempo de vida es un contador que se utiliza para limitar el tiempo de vida de
los paquetes. Cuando se llega a cero, el paquete se destruye. La unidad de tiempo es el
segundo, permitiéndose un tiempo de vida máximo de 255 segundos. Tamaño 8 bits.
Cuando la capa de red ha terminado de ensamblar un datagrama completo, necesitará
saber qué hacer con él. El campo Protocolo indica, a qué proceso de transporte
pertenece el datagrama. El TCP es efectivamente una posibilidad, pero en realidad hay
muchas más.
Protocolo: El número utilizado en este campo sirve para indicar a qué protocolo
pertenece el datagrama que se encuentra a continuación de la cabecera IP, de manera
que pueda ser tratado correctamente cuando llegue a su destino. Tamaño: 8 bit.
El código de redundancia de la cabecera es necesario para verificar que los datos
contenidos en la cabecera IP son correctos. Por razones de eficiencia este campo no
puede utilizarse para comprobar los datos incluidos a continuación, sino que estos datos
de usuario se comprobarán posteriormente a partir del código de redundancia de la
cabecera siguiente, y que corresponde al nivel de transporte. Este campo debe calcularse
de nuevo cuando cambia alguna opción de la cabecera, como puede ser el tiempo de
vida. Tamaño: 16 bit
La Dirección de origen contiene la dirección del host que envía el paquete. Tamaño: 32
bit.
La Dirección de destino: Esta dirección es la del host que recibirá la información. Los
routers o gateways intermedios deben conocerla para dirigir correctamente el paquete.
Tamaño: 32 bit.
Dejar un comentario
· 3:41 am
UNIDAD 3: Protocolo de Internet (IP)
3.1 Esquema de Direccionamiento IP
3.2 Jerarquía de Direcciones IP
Las redes deben ser segmentadas por aspectos de rendimiento, seguridad y
administración.
Para dividir redes, necesitamos el direccionamiento jerárquico, el cual identifica
cada host de manera exclusiva, pero también identifica a las redes. Este
direccionamiento jerárquico puede ser de 2 niveles o 3 niveles.
Jerarquía de dos niveles (sin subnetting).

Cada dirección en el bloque se puede considerar como una estructura
jerárquica de dos niveles:
Los n bits más a la izquierda (prefijo) definen la red.
Los 32 – n bits más a la derecha (sufijo) definen el nodo.
Jerarquía de tres niveles (subnetting)
La división de un grupo en subredes, crea tres niveles jerárquicos:
Los n bits más a la izquierda (prefijo) definen la red.
Los nx bits que siguen al prefijo de red definen la subred.
Los 32 – ( n + nx ) bits más a la derecha (sufijo) definen el nodo.
3.3 Clases de Direcciones IP
La notación que se utiliza para expresar una dirección IP se conoce como
notación por puntos:
Consiste en expresar los 4 octetos de la dirección en formato decimal
separados por puntos. Cada uno de estos números varía entre 0 y 255. Por
ejemplo:
Los Campos que componen la dirección IP:
CAMPO DE RED.- El número que identifica la red a la que se conecta
un dispositivo.
CAMPO DE HOST.- Corresponde al host o dispositivo específico de esa
red.

Estas direcciones IP se clasifican en 5 clases: A, B, C, D y E. El factor que va a
determinar la clase de una IP va a ser el octeto 1. En la actualidad se usan sólo
las clases A, B y C, las clases D y E, se usan sólo para fines de estudio e
investigación.
Veamos los posibles rangos.
A continuación se describen las clases de IP y las organizaciones que
típicamente reciben esa asignación.
Clase A:
Se diseñó para admitir redes de tamaño extremadamente grande.
Consta de 126 redes, estas redes consisten en 16.777.214 direcciones
posibles que se pueden asignar a los dispositivos y los ordenadores.
Las direcciones IP Clase A utilizan sólo el primer octeto para indicar la
dirección de la red. Los tres octetos restantes son para las direcciones
host.
El valor más alto que se puede representar es 01111111, 127 decimal.
Estos números 0 y 127 quedan reservados y no se pueden utilizar como
direcciones de red. Cualquier dirección que comience con un valor entre
1 y 126 en el primer octeto es una dirección Clase A.
Clase B:
La dirección Clase B se diseñó para cumplir las necesidades de redes
de tamaño moderado a grande.

Esta clase se compone de 16.384 redes individuales, cada una contiene
65.534 direcciones IP posibles.
Una dirección IP Clase B utiliza los primeros dos de los cuatro octetos
para indicar la dirección de la red. Los dos octetos restantes especifican
las direcciones del host.
Los primeros dos bits del primer octeto de la dirección Clase B siempre
son 10. Los seis bits restantes pueden poblarse con unos o ceros. Por lo
tanto, el menor número que puede representarse en una dirección Clase
B es 10000000, 128 decimal. El número más alto que puede
representarse es 10111111, 191 decimal. Cualquier dirección que
comience con un valor entre 128 y 191 en el primer octeto es una
dirección Clase B.
Clase C:
En general se asigna a las medianas y pequeñas empresas.
Hay un total de 2.097.152 redes clase C disponibles, cada una
compuesta de 255 direcciones IP individuales.
Las redes de clase C utilizan los tres primeros segmentos de dirección
como identificador de red y sólo el último segmento para identificar el
ordenador.
Una dirección Clase C comienza con el binario 110. Por lo tanto, el
menor número que puede representarse es 11000000, 192 decimal. El
número más alto que puede representarse es 11011111, 223 decimal. Si
una dirección contiene un número entre 192 y 223 en el primer octeto,
es una dirección de Clase C.
Clase D:
La dirección Clase D se creó para permitir multicast en una dirección IP.
Una dirección multicast es una dirección exclusiva de red que dirige los
paquetes con esa dirección destino hacia grupos predefinidos de
direcciones IP. Por lo tanto, una sola estación puede transmitir de forma
simultánea una sola corriente de datos a múltiples receptores.
Los primeros cuatro bits de una dirección Clase D deben ser 1110. Por
lo tanto, el primer rango de octeto para las direcciones Clase D es
11100000 a 11101111, o 224 a 239. Una dirección IP que comienza con
un valor entre 224 y 239 en el primer octeto es una dirección Clase D.

Clase E:
Las direcciones de la clase E están reservadas para uso experimental.
Los primeros cuatro bits de una dirección Clase E siempre son 1s. Por lo
tanto, el rango del primer octeto para las direcciones Clase E es
11110000 a 11111111, o 240 a 255.
En conclusión:
3.4 Mascaras de Subred
Subred
En 1985, RFC 950 definió un procedimiento estándar para soportar la división
en subredes (“Subnetting”) de una dirección de Clase A, B o C. El
direccionamiento de subred se introdujo para solucionar algunos de los
problemas que estaban empezando a surgir en Internet como consecuencia de
la jerarquía de direccionamiento en dos niveles de cada una de las clases:
Las tablas de encaminamiento de Internet estaban creciendo sustancialmente.
Los administradores locales debían pedir un nuevo identificador de red
cada vez que querían instalar una nueva red en su organización, aun
cuando no hubieran agotado el espacio de direcciones del que
disponían.
Ambos problemas fueron atacados añadiendo otro nivel de jerarquía en la
estructura de direcciones IP. En lugar de la jerarquía de dos niveles, el
direccionamiento de subred soporta una jerarquía de tres niveles. La Figura 1
ilustra la idea básica del direccionamiento de subred, que es dividir el
identificador de nodo estándar de las clases básicas en dos partes, un
identificador o número de subred y el identificador de nodo en dicha subred.

Figura 1. Jerarquías de Direccionamiento de Subred
Mascara
La máscara permite distinguir los bits que identifican la red y los que identifican
el host de una dirección IP, está conformado por un número de 32 bits, cuyo
valor se forma bajo las siguientes reglas:
Los dígitos 1 (unos) en la máscara de subred corresponden a la posición
del identificativo de red es decir al netID y al número de subred en la
dirección IP.
Los dígitos 0 (ceros) en la máscara de subred corresponde al número
de host.
La figura 2 muestra la aplicación de estas reglas. Aquí se emplea un número de
red clase B para subnetting. Se asignan 8 bits del campo de hostID como
número de subred. La máscara de subred es un patrón de 32 bits y
convencionalmente se escribe en la forma de notación decimal con puntos.
Ésta se muestra también en la figura. Debido que a un grupo de ocho dígitos 1
(unos) corresponde al valor decimal de 255, la máscara de subred puede
escribirse de la siguiente manera: 255.255.0.0.
Figura 2. Re presentación de máscara de subred(subnet mask)
En la siguiente tabla muestra las mascaras de red correspondientes a cada
clase, como una red clase tiene 8 bits para red y 24 bits para host, la mascara
de red 8 bits en uno y 24 bits en cero.

Tabla 1. Máscara por defecto
Para que un dispositivo conozca la direccion de la subred aplica la operación
AND booleana entre la direccion IP y la máscara de subred. Cuando se aplica
la máscara de subred a la dirección IP, se ponen en 0 los bits del sufijo de
hosts. La máscara de subred fija los bits del prefijo de red y de subred. Esta
operación es realizada por los routers para tomar decisiones de enrutamiento.
Por ejemplo:
Para calcular las subredes se aplica la siguiente fórmula:
o Para el caso de las subredes: Es 2 elevado a la cantidad de bits
(los unos), que se tomaron para crear subredes menos 2: 2[bits
de subred] – 2
o Para el caso de los Hosts: Es 2 elevado a la cantidad restante
desde host que quedan (los ceros): 2[bits de hosts] – 2
El “menos 2” es debido a que se descartan las direcciones de subred y de
broadcasts de la red, aplicando estas fórmulas se obtiene las cantidades de
subredes y de hosts por subred utilizables.
3.5 Protocolos de Resolución de Direcciones: ARP y RARP
Aunque en Internet cada máquina tiene una (o más) direcciones IP, en realidad
éstas no pueden usarse para enviar paquetes porque el hardware de capa de
enlace de datos no entiende las direcciones de Internet. Hoy día, la mayoría de
los hosts en las compañías y universidades se une a una LAN por una tarjeta
de red que sólo entiende direcciones LAN.
El Protocolo de resolución de direcciones (ARP) es un estándar TCP/IP
necesario que está definido en RFC 826, “Address Resolution Protocol”. ARP
resuelve direcciones IP que utiliza el software basado en TCP/IP para las
direcciones de control de acceso a medios empleadas por el hardware de LAN,
es decir es responsable de convertir las dirección de protocolo de alto nivel
(direcciones IP) a direcciones de red físicas. ARP se emplea en redes IEEE
802 además de en las viejas redes DIX Ethernet para mapear direcciones IP a
dirección hardware.
ARP proporciona los siguientes servicios de protocolo a hosts que se
encuentran en la misma red física:
Las direcciones de control de acceso a medios se obtienen mediante
una solicitud de difusión de red en forma de la pregunta “¿Cuál es la

dirección de control de acceso a medios de un dispositivo configurado
con la dirección IP adjunta?”
Cuando se responde a una solicitud ARP, el remitente de la respuesta
ARP y el solicitante de ARP original registran sus direcciones IP y de
control de acceso a medios respectivos como una entrada en una tabla
local, llamada la caché de ARP, para su uso posterior como referencia.
El hardware creado para uso en redes LAN debe contener una dirección única
que el fabricante programa en el dispositivo. En el hardware para redes LAN
Ethernet y Token Ring, esta dirección se conoce como la dirección de control
de acceso a medios.
Cada dirección de control de acceso a medios identifica el dispositivo en su
propia red física con un número de 6 bytes programado en la memoria de sólo
lectura de cada dispositivo de hardware físico, por ejemplo, un adaptador de
red. Las direcciones de control de acceso a medios suelen mostrarse en
formato hexadecimal (por ejemplo, 00-AA-00-3F-89-4A).
Cómo resuelve ARP las direcciones de control de acceso a medios para el
tráfico local
La siguiente ilustración muestra cómo resuelve ARP las direcciones IP en
direcciones de hardware de hosts que se encuentran en la misma red local.
En este ejemplo, dos hosts TCP/IP, los hosts A y B, se encuentran en la misma
red física. El host A tiene asignada la dirección IP 10.0.0.99 y el host B la
dirección IP 10.0.0.100.
Cuando el host A intenta comunicarse con el host B, los siguientes pasos
permiten resolver la dirección asignada por el software al host B (10.0.0.100)
en la dirección de control de acceso a medios asignada por el hardware al host
B:
1. Según el contenido de la tabla de enrutamiento del host A, IP determina
que la dirección IP de reenvío que se va a utilizar para llegar al host B es
10.0.0.100. Después, el host A busca en su propia caché de ARP local
una dirección de hardware coincidente para el host B.
2. Si el host A no encuentra ninguna asignación en la caché, difunde una
trama de solicitud ARP a todos los hosts de la red local con la pregunta
“¿Cuál es la dirección de hardware para 10.0.0.100?” Las direcciones de
hardware y software del origen, el host A, se incluyen en la solicitud
ARP.

3. Cada host de la red local recibe la solicitud ARP y comprueba si coincide
con su propia dirección IP. Si el host no encuentra una coincidencia,
descarta la solicitud ARP.
4. El host B determina que la dirección IP especificada en la solicitud ARP
coincide con su propia dirección IP y agrega una asignación de
direcciones de hardware y software para el host A a su caché de ARP
local.
5. El host B envía directamente un mensaje de respuesta de ARP que
contiene su dirección de hardware al host A.
6. Cuando el host A recibe el mensaje de respuesta de ARP del host B,
actualiza su caché de ARP con una asignación de direcciones de
hardware y software para el host B.
Una vez determinada la dirección de control de acceso a medios del host B, el
host A puede enviar al host B tráfico IP que se dirigirá a la dirección de control
de acceso a medios del host B.
Cómo resuelve ARP las direcciones de control de acceso a medios para el
tráfico remoto
ARP también se utiliza para reenviar datagramas IP a enrutadores locales de
destinos que no se encuentran en la red local. En estos casos, ARP resuelve la
dirección de control de acceso a medios de la interfaz de un enrutador en la red
local.
En la siguiente ilustración se muestra cómo resuelve ARP las direcciones IP en
direcciones de hardware de dos hosts que se encuentran en redes físicas
diferentes conectadas por un enrutador común.
En este ejemplo, el host A tiene asignada la dirección IP 10.0.0.99 y el host B la
dirección IP 192.168.0.99. La interfaz del enrutador 1 se encuentra en la misma
red física que el host A y utiliza la dirección IP 10.0.0.1. La interfaz del
enrutador 2 se encuentra en la misma red física que el host B y utiliza la
dirección IP 192.168.0.1.
Cuando el host A intenta comunicarse con el host B, los siguientes pasos
permiten resolver la dirección asignada por el software a la interfaz del
enrutador 1 (10.0.0.1) en la dirección de control de acceso a medios asignada
por el hardware:

1. Según el contenido de la tabla de enrutamiento del host A, IP determina
que la dirección IP de reenvío que se va a utilizar para llegar al host B es
10.0.0.1, la dirección IP de la puerta de enlace predeterminada.
Después, el host A busca en su propia caché de ARP local una dirección
de hardware coincidente para 10.0.0.1.
2. Si el host A no encuentra ninguna asignación en la caché, difunde una
trama de solicitud ARP a todos los hosts de la red local con la pregunta
“¿Cuál es la dirección de hardware para 10.0.0.1?” Las direcciones de
hardware y software del origen, el host A, se incluyen en la solicitud
ARP.
3. Cada host de la red local recibe la solicitud ARP y comprueba si coincide
con su propia dirección IP. Si el host no encuentra una coincidencia,
descarta la solicitud ARP.
4. El enrutador determina que la dirección IP especificada en la solicitud
ARP coincide con su propia dirección IP y agrega una asignación de
direcciones de hardware y software para el host A a su caché de ARP
local.
5. Después, el enrutador envía directamente un mensaje de respuesta de
ARP que contiene su dirección de hardware al host A.
6. Cuando el host A recibe el mensaje de respuesta de ARP del enrutador,
actualiza su caché de ARP con una asignación de direcciones de
hardware y software para 10.0.0.1.
Una vez determinada la dirección de control de acceso a medios de la interfaz
del enrutador 1, el host A puede enviar a la interfaz del enrutador 1 tráfico IP
que se dirigirá a la dirección de control de acceso a medios de esa interfaz.
Posteriormente, el enrutador reenvía el tráfico al host B mediante el mismo
proceso ARP que se describe en esta sección.
Se pueden hacer varias optimizaciones para que ARP trabaje con más
eficiencia. Para empezar, una vez que una máquina ha ejecutado ARP, guarda
el resultado en caso de tener que ponerse en poco tiempo de nuevo en
contacto con la misma máquina. La siguiente vez encontrará la
correspondencia en su propio caché, eliminando así la necesidad de una
segunda difusión.
Para permitir que las correspondencias cambien, por ejemplo, cuando una
tarjeta Ethernet falla y se reemplaza con una nueva (y, por lo tanto, una nueva
dirección Ethernet), las entradas en el caché ARP deben expirar en unos
cuantos minutos.
La ventaja de usar ARP en lugar de archivos de configuración es la sencillez. El
gerente de sistemas sólo tiene que asignar a cada máquina una dirección IP y
decidir respecto de las máscaras de subred. ARP hace el resto.
RARP (Protocolo de Resolución de Dirección de Retorno)
ARP resuelve el problema de encontrar qué dirección Ethernet corresponde a
una dirección IP dada. A veces se tiene que resolver el problema inverso: dada
una dirección Ethernet, ¿cuál es la dirección IP correspondiente? En particular,
este problema ocurre cuando se inicializa una estación de trabajo sin disco.

La primera solución inventada fue usar el RARP (Protocolo de Resolución de
Dirección de Retorno) (su definición está en el RFC 903). Este protocolo
permite que una estación de trabajo recientemente inicializada transmita su
dirección Ethernet y diga: “Mi dirección Ethernet de 48 bits es
14.04.05.18.01.25. ¿Alguien allá afuera conoce mi dirección IP?” El servidor
RARP ve esta solicitud, busca la dirección Ethernet en sus archivos de
configuración y devuelve la dirección IP correspondiente.
Usar RARP es mejor que incrustar una dirección IP en la imagen de memoria
porque esto permite usar la misma imagen en todas las máquinas. Si la
dirección IP se incrustara en la imagen, cada estación de trabajo necesitaría su
propia imagen.
Una desventaja de RARP es que usa una dirección de destino de todos los 1s
(de difusión limitada) para llegar al servidor RARP. Sin embargo, dichas
difusiones no las envían los enrutadores, por lo que se necesita un servidor
RARP en cada red.
3.6 Datagramas IP
Los datos circulan en Internet en forma de datagramas (también conocidos
como paquetes). Los datagramas son datos encapsulados, es decir, datos a los
que se les agrega un encabezado que contiene información sobre su transporte
(como la dirección IP de destino).
Los routers analizan (y eventualmente modifican) los datos contenidos en un
datagrama para que puedan transitar.
A continuación se indica cómo se ve un datagrama:
A continuación se indican los significados de los diferentes campos:

Versión (4 bits): es la versión del protocolo IP que se está utilizando
(actualmente se utiliza la versión 4 IPv4) para verificar la validez del
datagrama. Está codificado en 4 bits.
Longitud del encabezado o IHL por Internet Header Length (Longitud del
encabezado de Internet) (4 bits): es la cantidad de palabras de 32 bits
que componen el encabezado (Importante: el valor mínimo es 5). Este
campo está codificado en 4 bits.
Tipo de servicio (8 bits): indica la forma en la que se debe procesar el
datagrama.
Longitud total (16 bits): indica el tamaño total del datagrama en bytes. El
tamaño de este campo es de 2 bytes, por lo tanto el tamaño total del
datagrama no puede exceder los 65536 bytes. Si se lo utiliza junto con el
tamaño del encabezado, este campo permite determinar dónde se
encuentran los datos.
Identificación, indicadores y margen del fragmento son campos que
permiten la fragmentación de datagramas. Esto se explica a
continuación.
TTL o Tiempo de vida (8 bits): este campo especifica el número máximo
de routers por los que puede pasar un datagrama. Por lo tanto, este
campo disminuye con cada paso por un router y cuando alcanza el valor
crítico de 0, el router destruye el datagrama. Esto evita que la red se
sobrecargue de datagramas perdidos.
Protocolo (8 bits): este campo, en notación decimal, permite saber de
qué protocolo proviene el datagrama.
ICMP 1
IGMP: 2
TCP: 6
UDP: 17
Suma de comprobación del encabezado (16 bits): este campo contiene
un valor codificado en 16 bits que permite controlar la integridad del
encabezado para establecer si se ha modificado durante la transmisión.
La suma de comprobación es la suma de todas las palabras de 16 bits
del encabezado (se excluye el campo suma de comprobación). Esto se
realiza de tal modo que cuando se suman los campos de encabezado
(suma de comprobación inclusive), se obtenga un número con todos los
bits en 1.
Dirección IP de origen (32 bits): Este campo representa la dirección IP
del equipo remitente y permite que el destinatario responda.
Dirección IP de destino (32 bits): dirección IP del destinatario del
mensaje.
3.7 Ruteo IP
El enrutamiento IP es una parte integral de la capa de Internet del conjunto
TCP/IP. El enrutamiento consiste en asegurar el enrutamiento de un datagrama
de IP a través de la red por la ruta más corta. A esta función la llevan a cabo
los equipos denominados routers, es decir, equipos que conectan al menos dos
redes.

En términos generales, el enrutamiento es el proceso de reenviar paquetes
entre dos redes conectadas. En cuanto a las redes basadas en TCP/IP, el
enrutamiento forma parte del Protocolo Internet (IP) y se utiliza junto con otros
servicios de protocolo de red para proporcionar capacidades de reenvío entre
hosts que se encuentran en segmentos de red distintos dentro de una red
basada en un TCP/IP más grande.
IP es la “oficina de correos” del protocolo TCP/IP, donde se ordenan y entregan
los datos IP. Cada paquete entrante o saliente se denomina datagrama IP. Un
datagrama IP contiene dos direcciones IP: la dirección de origen del host que
realiza el envío y la dirección de destino del host receptor. A diferencia de las
direcciones de hardware, las direcciones IP de un datagrama siguen siendo las
mismas durante su transmisión a través de una red TCP/IP.
El enrutamiento es la función principal de IP. Los datagramas IP se
intercambian y procesan en cada host mediante IP en el nivel de Internet.
Por encima del nivel IP, los servicios de transporte del host de origen
transmiten los datos en forma de segmentos TCP o mensajes UDP al nivel IP.
El nivel IP ensambla los datagramas IP con la información de las direcciones
de origen y destino, que se utiliza para enrutar los datos a través de la red. A
continuación, el nivel IP transmite los datagramas al nivel de interfaz de red. En
este nivel, los servicios de vínculos de datos convierten los datagramas IP en
tramas para la transmisión en una red física a través de medios específicos de
la red. Este proceso se produce en el orden inverso en el host de destino.
Cada datagrama IP contiene una dirección IP de origen y de destino. En cada
host, los servicios del nivel IP examinan la dirección de destino de cada
datagrama, comparan esta dirección con una tabla de enrutamiento mantenida
localmente y, después, deciden qué acción de reenvío se debe realizar. Los
enrutadores IP están conectados a dos o más segmentos de red IP habilitados
para reenviar paquetes entre ellos. Las siguientes secciones tratan con más
detalle los enrutadores IP y el uso de tablas de enrutamiento.
Los segmentos de red TCP/IP están conectados entre sí mediante enrutadores
IP, que son los dispositivos que transmiten los datagramas IP desde un
segmento de red a otro.
Los enrutadores IP proporcionan el medio principal para unir dos o más
segmentos de red IP separados físicamente. Todos los enrutadores IP
comparten dos características fundamentales:
Los enrutadores IP son de hosts múltiples. Un equipo de hosts múltiples
es un host de red que utiliza dos o más interfaces de conexión de red
para conectarse a cada segmento de red separado físicamente.
Los enrutadores IP permiten el reenvío de paquetes a otros hosts
TCP/IP. Los enrutadores IP se diferencian de otros hosts multitarjeta en
una característica importante: un enrutador IP debe ser capaz de
reenviar la comunicación basada en IP entre redes para otros hosts de
la red IP.

Los enrutadores IP se pueden implementar mediante varios productos de
hardware y software posibles. Comúnmente se utilizan enrutadores basados en
hardware (dispositivos de hardware dedicados que ejecutan software
especializado). Además, se pueden utilizar soluciones de enrutamiento
basadas en software, como los servicios de enrutamiento y acceso remoto.
3.8 Encapsulamiento IP – Omar Aguirre
Todas las comunicaciones de una red se originan en una fuente y son enviadas
a un destino. El encapsulamiento envuelve los datos con la información de
protocolo necesaria antes de transitar por la red. Así, mientras la información
se mueve hacia abajo por las capas del modelo OSI, cada capa añade un
encabezado, y un trailer si es necesario, antes de pasarla a una capa inferior.
Los encabezados y trailers contienen información de control para los
dispositivos de red y receptores para asegurar la apropiada entrega de los
datos y que el receptor interprete correctamente lo que recibe.
Paso 1: los datos de usuario son enviados por una aplicación a la capa de
aplicación.
Paso 2: La capa de aplicación añade el encabezado (layer 7 Header) a los
datos, el encabezado y los datos originales pasan a la capa de presentación.
Paso 3: La capa de presentación recibe los datos provenientes de la capa
superior, incluyendo el encabezado agregado, y los trata como sólo datos,
añade su encabezado a los datos, y los pasa a la capa de sesión
Paso 4: la capa de sesión recibe los datos y añade su encabezado, lo pasa a la
capa de transporte.
Paso 5: la capa de transporte recibe los datos y añade su encabezado, pasa
los datos a la capa inferior.

Paso 6: la capa de red añade su encabezado y los pasa a la capa de enlace de
datos.
Paso 7: la capa de enlace de datos añade el encabezado y un trailer (cola) a
los datos, usualmente es un Frame Check Sequence, que usa el receptor para
detectar si los datos enviados están o no en error. Esto envuelve los datos que
son pasados a la capa física.
Paso 8: la capa física entonces transmite los bits hacia el medio de red.
Ejemplo:
Se tienen 60 bytes del datagrama, ordenados en grupos de 8 bytes por renglón
para su fácil lectura, y con la numeración en valores hexadecimales:
1 000000: 45 00 00 3C 82 47 00 00 E..<.G..
2 000008: 20 01 94 C9 C0 A8 01 01 ……
3 000010: C0 A8 01 11 08 00 48 5C …@..H
4 000018: 01 00 04 00 61 62 63 64 ….abcd
5 000020: 65 66 67 68 69 6A 6B 6C efghijkl
6 000028: 6D 6E 6F 70 71 72 73 74 mnopqrst
7 000030: 75 76 77 61 62 63 64 65 uvwabcde
8 000038: 66 67 68 69 fghi
Ahora bien, ¿qué es lo que nos dice esta información?
Los primeros 4 bits nos indican que es un datagrama versión 4 (IPv4).

El siguiente campo nos indica que tiene una longitud de 5 palabras, cada
una de 4 bytes; y el mínimo es 5.
El tipo de servicio nos indica la calidad de servicio QoS, anteriormente
era el campo de precedencia y se cambió para dar lugar al etiquetado de
DCSP (Differentiated Services Code Point; RFC 2474); en este caso, al
ser un paquete de ICMP no tiene prioridad.
La longitud total del datagrama, en este caso 60 bytes.
El campo de identificación sirve para distinguir un datagrama de otro.
Las banderas nos indican que se puede fragmentar este datagrama si
fuera necesario y que es el último fragmento.
El offset nos asegura que se utilicen los primeros 8 bytes del
encabezado
3.9 Transmisión de Datagramas IP – Omar Aguirre
El hardware sólo acepta la transmisión y entrega de paquetes que
cumplan con el formato y requerimientos específicos de ese hardware.
Para transportar un paquete IP, el transmisor debe proporcionar el
paquete y la dirección física del destino.
Cuando la trama llega a un nodo, éste extrae los datos y los encapsula
en la trama de la siguiente red.
3.10 IPv6
Protocolo de internet encargado de dirigir los paquetes a través de una red.
Diseñado por Steve Deering de Xerox PARC y Craig Mudge.
IPv6 fue diseñada para sustituir la versión actual IPv4 que tiene grandes
limitaciones, especialmente porque cuenta con un número limitado de
direcciones de red posibles.
IPv6 soporta 340.282.366.920.938.463.463.374.607.431.768.211.456 (2
elevado a 128) de direcciones, mientras que IPv4 sólo 4.294.967.296 (2
elevado a 32).

El uso de IPv6 ha sido frenado temporalmente por el uso de la traducción de
direcciones de red (NAT), que alivia parcialmente el problema del faltante de
direcciones IP. El problema es que NAT hace difícil o imposible el uso de voz
sobre IP (VoIP), los juegos multiusuarios y las aplicaciones P2P.
Se estima que IPv4 seguirá funcionando hasta 2025, por la falta de renovación
de dispositivos que sólo funcionan con este protocolo.
Un ejemplo de una dirección IP en versión 6 es:
2001:0db8:85a3:08d3:1319:8a2e:0370:7334
Algunos de los cambios de IPv4 a IPv6 más relevantes son:
Capacidad extendida de direccionamiento
Autoconfiguración de direcciones libres de estado
Multicast
Seguridad de nivel obligatoria
Procesamiento simplificado en los routers
Movilidad
Soporte mejorado para las extensiones y opciones, Jumbogramas.
Identificación de los tipos de direcciones
Los tipos de direcciones IPv6 pueden identificarse tomando en cuenta los
rangos definidos por 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/127
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.
::1.2.3.4/96
La dirección IPv4 compatible se usa como un mecanismo de transición en las
redes duales IPv4/IPv6. Es un mecanismo que no se usa.

::ffff:0:0/96
La dirección IPv4 mapeada se usa como mecanismo de transición en
terminales duales.
fe80::/10
El prefijo de enlace local (en inglés link local) específica que la dirección sólo es
válida en el enlace físico local.
fec0::
El prefijo de emplazamiento local (en inglés site-local 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. Se deben sustituir por
direcciones Local IPv6 Unicast.
ff00::/8
El prefijo de multicast. Se usa para las direcciones multicast.
Hay que resaltar que no existen las direcciones de difusión ( broadcast) en
IPv6, aunque la funcionalidad que prestan puede emularse utilizando la
dirección multicastFF01::1/128, denominada todos los nodos (all nodes)
Paquete IPv6
Un paquete en IPv6 está compuesto principalmente de dos partes: la cabecera
(que tiene una parte fija y otra con las opciones) y la carga útil (los datos).
Cabecera Fija
Los primeros 40 bytes (320 bits) son la cabecera del paquete y contiene los
siguientes campos:
Direcciones de origen (128 bits)
Direcciones de destino (128 bits)
Versión del protocolo ip (4 bits)
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)
Límite de saltos (8 bits, tiempo de vida).

Cabeceras de extensión
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. La Cabecera principal, tiene a diferencia de la
cabecera de la versión IPv4 un tamaño fijo de 40 octetos.Específica para
asignarlos para aplicaciones multicast intra-dominio o entre-dominios (RFC
3306). En IPv4 era muy difícil para una organización.
Carga Útil
La carga útil del paquete puede tener un tamaño de hasta 64 KB en modo
estándar, o mayor con una opción de carga jumbo (jumbo payload) en el
encabezado opcional Hop-By-Hop.
La fragmentación es manejada solamente en el host que envía la información
en IPv6: los routers nunca fragmentan un paquete y los hosts se espera que
utilicen el Path MTU discovery.
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 quad-A, por
tener una longitud cuatro veces la de los registros A para IPv4).
El concepto de AAAA fue una de las dos propuestas al tiempo que se estaba
diseñando la arquitectura IPv6. La otra propuesta utilizaba registros A6 y otras
innovaciones como las etiquetas de cadena de bits (bit-string 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.
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.

Mecanismos de transición a IPv6
Ante el agotamiento de las direcciones IPv4, y los problemas que este está
ocasionando ya, sobretodo en los países emergentes de Asia como India o
China, el cambio a IPv6 ya ha comenzado. Se espera que convivan ambos
protocolos durante un año, aunque se piensa que la implantación mundial y
total en internet de IPv6 se hará realidad hacia finales de 2012, dada la
celeridad con la que se están agotando las direcciones IPv4. La red no podrá
aguantar mucho más sin el cambio, y de no realizarse pronto este las
consecuencias podrían ser muy graves. 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:
Doble pila
Túneles
Traducción
IPv6
IPng
Protocolos de Ruteo
-RIPng ó RIPv6
-OSPFv3
-EIGRPv6
-IS-IS para IPv6
-BGP4+
Arquitectura jerárquica
Configuración automática
Multicast y Anycast
Seguridad Obligatoria
Identificación QoS
Autoconfiguración
Stateless, Stateful
Mecanismos de Transición
Capa IP dual
Encapsulamiento (Túnel)
Traducción

Sintáxis
FEDC:ba98:7654:3210:FEDc:BA98:7654:3210
FF05:0:0:0:0:0:0:B3>>>FF05::B3
::132.248.204.49
Tipos de Direcciones
Unicast, Anycast, Multicast
Direcciones de 128 bits
Dejar un comentario
· 3:39 am
UNIDAD 4: Protocolo de Datagramas de
Usuario (UDP)
Internet tiene dos protocolos principales en la capa de transporte, uno orientado y otro
no orientado a la conexión, mejor conocido como UDP. Este protocolo proporciona una
forma para que las aplicaciones envíen datagramas IP encapsulados sin tener que
establecer una conexión. UDP está descrito en el RFC 768.
Ilustración 1 – UDP de forma gráfica
UDP cuenta con las siguientes características:

Sin conexión Los nodos envían mensajes UDP, que consta de un
encabezado UDP y un mensaje, sin tener que negociar una conexión entre los
compañeros de comunicación.
Poco fiable Los nodos envían mensajes como datagramas UDP sin
secuencia o reconocimiento. El protocolo de capa de aplicación debe reordenar y
recuperar los mensajes perdidos. Los protocolos basados en UDP de capa de
aplicación deben ofrecer su propio servicio confiable o retransmitir mensajes
UDP periódicamente o después de un definido valor de tiempo.
Ofrece identificación de los protocolos de la capa de aplicación UDP
proporciona un mecanismo para enviar mensajes a un protocolo de capa de
aplicación o proceso específico en un host de red interna. La cabecera UDP
proporciona la fuente y el proceso de identificación de destino.
Proporciona una suma de verificación (checksum) del mensaje UDP La
cabecera UDP otorga una suma de verificación de 16 bits del mensaje entero de
UDP.
UDP es un reflejo directo de los servicios de datagrama de IP, excepto que UDP
proporciona un método para pasar los datos a un protocolo de capa de aplicación.
UDP no proporciona los servicios de entrega siguientes:
Almacenamiento en el búfer UDP no proporciona ningún tipo de
almacenamiento en búfer de los datos entrantes o salientes. El protocolo de capa
de aplicación debe proporcionar todo el almacenamiento en búfer.
Segmentación UDP no proporciona ningún tipo de segmentación de los
grandes bloques de datos. Por lo tanto, la aplicación debe enviar los datos en
pequeños bloques suficientes para que los datagramas IP de los mensajes UDP
no sean mayores que la unidad de transmisión máxima (MTU en inglés) de la
interfaz en la que se envían. De lo contrario, IP envía los fragmentos al host del
mensaje UDP.
Control de flujo UDP no proporciona ningún control de flujo para el emisor ni
para el receptor. Los remitentes de mensajes UDP pueden reaccionar a la
recepción de un mensaje del Protocolo de Control de Mensajes de Internet
(ICMP), pero no es necesario.
4.1 Difusión y Multienvío
UDP transmite segmentos que consisten en un encabezado de 8 bytes seguido por la
carga útil. Existen dos puertos sirven para identificar los puntos terminales dentro de
las máquinas de origen y destino. Cuando llega un paquete UDP, su carga útil se entrega
al proceso que está enlazado al puerto de destino. De hecho, el valor principal de contar
con UDP en lugar de simplemente utilizar el IP puro es la adición de los puertos de
origen y destino. Sin los campos de puerto, la capa de transporte no sabría qué hacer con
el paquete. Con ellos, entrega los segmentos de manera correcta.
Un área en la que UDP es especialmente útil es en las situaciones cliente-servidor. Con
frecuencia, el cliente envía una solicitud corta al servidor y espera una respuesta corta.
Si se pierde la solicitud o la respuesta, el cliente simplemente puede terminar y probar
nuevamente. El código no sólo es simple, sino que se necesitan muy pocos mensajes

(uno en cada dirección) en comparación con un protocolo que requiere una
configuración inicial. Una aplicación que utiliza de esta manera a UDP es DNS (el
Sistema de Nombres de Dominio). En resumen, un programa que necesita buscar la
dirección IP de algún host puede enviar al servidor DNS un paquete UDP que contenga
el nombre de dicho host.
El servidor responde con un paquete UDP que contiene la dirección IP del host. No se
necesita configuración por adelantado ni tampoco liberación posterior. Sólo dos
mensajes viajan a través de la red.
Si el protocolo de capa de aplicación proporciona a sus propios servicios confiables de
entrega de datos, no hay necesidad de que el protocolo de capa de transporte los
otorgue. Ejemplos de protocolos fiables de capa de aplicación son Trivial File Transfer
Protocol (TFTP) y Network File System (NFS). Si el protocolo de capa de aplicación
periódicamente anuncia la información, la entrega confiable no es necesaria. Si un
anuncio se pierde, se anuncia de nuevo en un intervalo de tiempo. Un ejemplo de un
protocolo de capa de aplicación que anuncia entregas periódicamente es el Routing
Information Protocol (RIP).
UDP utiliza el protocolo RTP(Protocolo de Transporte en Tiempo Real) para poder
multiplexar varios flujos de datos en tiempo real en un solo flujo de paquetes. RTP
opera de la siguiente forma: La aplicación multimedia consiste en múltiples flujos de
audio, vídeo, texto, entre otros. Éstos se colocan en la biblioteca RTP, la cual está en el
espacio de usuario junto con la aplicación. Esta biblioteca multiplexa los flujos y los
codifica en paquetes RTP, que después coloca en un socket. En el otro extremo del
socket (en el kernel del sistema operativo), los paquetes UDP se generan e incrustan en
paquetes IP. Si la computadora está en una Ethernet, los paquetes IP se colocan a
continuación en tramas Ethernet para su transmisión.
El flujo UDP se puede enviar a un solo destino (unidifusión) o a múltiples
destinos (multidifusión). Debido a que RTP sólo utiliza UDP normal, sus paquetes no
son tratados de manera especial por los enrutadores, a menos que se habiliten algunas
características de calidad de servicio IP normales. En particular, no hay garantías
especiales acerca de la entrega, fluctuación, etcétera.
A cada paquete enviado en un flujo RTP se le da un número más grande que a su
predecesor. Esta numeración permite al destino determinar si falta algún paquete. Si
falta alguno, la mejor acción que el destino puede realizar es aproximar el valor faltante
mediante la interpolación. La retransmisión no es una opción práctica debido a que el
paquete retransmitido probablemente llegará muy tarde como para ser útil. En
consecuencia, RTP no tiene control de flujo, control de errores, confirmaciones de
recepción ni ningún mecanismo para solicitar retransmisiones.
Otra característica que se necesita es la marcación del tiempo (timestamping). La idea es
permitir que el origen asocie una marca de tiempo con la primera muestra de cada
paquete. Las marcas de tiempo son relativas al inicio del flujo, por lo que sólo son
importantes las diferencias entre dichas marcas de tiempo. Los valores absolutos no
tienen significado. Este mecanismo permite que el destino realice una pequeña cantidad
de almacenamiento en búfer y reproduzca cada muestra el número exacto de
milisegundos después del inicio del flujo, independientemente de cuándo llegó el

paquete que contiene la muestra. La marcación del tiempo no sólo reduce los efectos de
la fluctuación, sino que también permite que múltiples flujos estén sincronizados entre
sí.
4.2 Puertos de la Aplicaciones
Un puerto UDP define una ubicación o cola de mensajes para la entrega de mensajes
para los protocolos de la capa de aplicación que utilizan los servicios UDP. Se incluye
en cada mensaje UDP el puerto de origen (la cola de mensajes desde donde se envió el
mensaje) y un puerto de destino (la cola de mensajes a los que se envió el mensaje). La
Internet Assigned Numbers Authority (IANA) asigna números de puerto, conocidas
como los números de puerto, a los protocolos específicos de la capa de aplicación.
Número de
puerto
Protocolo de capa de aplicación
53 DNS
67 BOOT server (Dynamic Host Configuration Protocol[DHCP])
68 BOOT client (DHCP)
69 TFTP
137 NetBIOS Name Service
138 NetBIOS Datagram Service
161 Simple Network Management Protocol (SNMP)
445
Direct hosting of Server Message Block (SMB) datagrams over TCP/IP
(also known as Microsoft-DS)
520 RIP
1812, 1813 Remote Authentication Dial-In User Service (RADIUS)
Normalmente, el lado del servidor de un protocolo de capa de aplicación escucha en el
número de puerto conocido. El lado del cliente de un protocolo de capa de aplicación
utiliza ya sea el conocido número de puerto o, más comúnmente, un número de puerto
asignado dinámicamente. Estos números de puerto asignados dinámicamente se utilizan
para la duración del proceso y son también conocidos como puertos efímeros o de corta
duración.
Cuando se recibe un mensaje UDP en el destino, IP comprueba la cabecera IP y, con
base en el valor de 17 (0×11) en el campo de Protocolo, pasa el mensaje UDP, la
dirección IP de origen, así como la dirección IP de destino para el componente de UDP.
Después de verificar la suma de comprobación UDP, el componente de UDP verifica el
puerto de destino. Si un proceso está escuchando en el puerto, UDP pasa el mensaje a la
aplicación. Si ningún proceso está escuchando en el puerto, UDP utiliza el componente
ICMP para enviar mensaje de ―Destino de Puerto Inalcanzable‖ al remitente, y luego
descarta el mensaje UDP.
4.3 Direcciones de los Conectores
A la combinación de una dirección de IP y de puerto para una comunicación se le llama
dirección de conector o socket. Un socket ofrece toda la información que necesita un
cliente o un servidor para identificar a su otro extremo.

Cuando se crea un conector (socket) UDP, sus direcciones local y remota están sin
especificar. Se pueden enviar datagramas inmediatamente usando sendto o sendmsg con
una dirección de destino válida como argumento. Cuando se llama a connect sobre el
conector, se envía la dirección de destino por defecto y a partir de ese momento se
pueden enviar datagramas usando send o write sin especificar una dirección de destino.
Todavía es posible realizar envíos a otros destinos pasando una dirección a
sendto o sendmsg. Para poder recibir paquetes, primero se debe ligar el conector a una
dirección local usando bind. Cuando éste no sea el caso, la capa de conectores le
asignará automáticamente un puerto local en la primera petición de recepción del
usuario.
Todas las operaciones de recepción sólo devuelven un paquete. Cuando el paquete es
más pequeño que el buffer pasado, sólo se devuelven los datos del paquete y, cuando es
mayor, el paquete se trunca y la bandera MSG_TRUNC se activa.
Se pueden enviar o recibir opciones IP usando las opciones de conectores descritas en
IP. Estas son procesadas por el núcleo sólo cuando está activa la sysctl adecuada (pero
todavía se pasan al usuario incluso cuando está desactivada). Cuando en un envío está
activa la opción MSG_DONTROUTE, la dirección de destino debe referirse a la
dirección de una interfaz local y el paquete sólo se envía a esa interfaz.
UDP fragmenta un paquete cuando su longitud total excede la MTU (Unidad de
Transmisión Máxima) de la interfaz. Una alternativa de red más amigable es usar el
descubrimiento de la MTU de la ruta como se describe en la sección
IP_PMTU_DISCOVER de IP.
Para el formato de dirección, UDP utiliza el formato sockaddr_in de IPv4 el cual nos
dice que una dirección de conector IP se define como una combinación de una
dirección de interfaz IP y un número de puerto. El protocolo IP básico no proporciona
números de puerto. En los conectores directos, a sin_port se le asigna el protocolo IP.
Ilustración 2 – Estructura de sockaddr_in
A sin_family siempre se le asigna el valor AF_INET. sin_port contiene el puerto con
los bytes en orden de red. Los números de puerto por debajo de 1024 se llaman puertos
reservados. Sólo los procesos con identificador de usuario efectivo 0 o la capacidad
CAP_NET_BIND_SERVICE pueden realizar enlaces mediante bind a estos
conectores. sin_addr es la dirección IP del anfitrión (host). El miembro s_addr de struct

in_addr contiene la dirección de la interfaz del anfitrión con los bytes en orden de red.
Sólo se debería acceder a in_addr usando las funciones de biblioteca net_aton, inet_addr
e inet_makeaddr, o directamente mediante el mecanismo de resolución de nombres.
Las direcciones IPv4 se dividen en direcciones unidestino, de difusión y multidestino.
Las direcciones unidestino especifican una única interfaz de un anfitrión, las direcciones
de difusión especifican todos los anfitriones de una red y las direcciones multidestino
identifican a todos los anfitriones de un grupo multidestino. Sólo se pueden enviar
datagramas o recibir datagramas de direcciones de difusión cuando está activa la opción
de conector SO_BROADCAST.
4.4 Formatos de los Mensajes UDP
Longitud del mensaje UDP (16 bits). Especifica la longitud media en bytes del mensaje
UDP, incluyendo la cabecera. Longitud mínima es de 8 bytes.
Suma de verificación UDP (16 bits, opcional). Suma de comprobación de errores del
mensaje. Para cálculo se utiliza una pseudo – cabecera 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.
4.5. Encapsulado de UDP
Los mensajes UDP están encapsulados y se envían en datagramas IP, como se muestra
en la siguiente ilustración.
MAPAS CONCEPTUALES.

Dejar un comentario
· 3:37 am
UNIDAD 5: Protocolo de Control de
Transmisión (TCP)
5.1 Servicio de Transportación Confiable

*TCP (Transmission Control Protocol) es el protocolo de la familia TCP/IP que provee
servicio de transporte de datos en forma confiable.
*TCP está implementado sobre IP, por lo tanto debe resolver los problemas no resueltos
por IP -datagramas se pueden perder, estar duplicados, llegar fuera de orden.
*Este protocolo es fundamental en sistemas de computación ya que modela el
comportamiento de un canal ideal, como el supuesto en las comunicaciones con otros
dispositivos de I/O.
*TCP resuelve el problema de muy buena forma, por ello ha perdurado por varias
décadas, y ningún otro protocolo con iguales servicios ha probado ser mejor.
5.2 Funciones y Servicios de TCP
*Orientación a conexión (Connection Orientation): La aplicación debe requerir una
conexión primero. Una vez establecida la usa. Finalmente la cierra.
*Comunicación Punto-a-Punto: Cada conexión tiene exactamente dos terminales
(comparar con comunicación multipunto -multicast)
*Confiabilidad total (Complete Reliability): Se garantiza entrega de los datos sin
pérdidas ni duplicados y en orden.
*Comunicación dúplex integral (Full Duplex): Hay un buffer de envío y otro de
recepción.
*El protocolo efectúa estas tareas en trasfondo y sin bloquear la aplicación -salvo para
recepción de datos que aún no han llegado.
5.3 Mecanismos Básicos de TCP
5.3.1 Flujo de Datos
Los segmentos, al viajar en datagramas IP, pueden llegar en cualquier orden, perderse,
llegar duplicados, etc. Es responsabilidad de TCP resolver todos estos problemas y
generar un flujo de bits fiable a nivel de aplicación. En ningún caso viajará en un mismo
datagrama más de un segmento. Tampoco se combinarán nunca en un segmento datos
provenientes de dos conexiones TCP diferentes.
Las aplicaciones que comunican haciendo uso de los servicios TCP no tienen conciencia
de la existencia de segmentos o datagramas. Para ellas la comunicación se realiza como
un flujo continuo de bits (stream), como si hubiera un hilo físico que las comunicara. Si
desean que la información sea transmitida a la aplicación receptora en mensajes
discretos deberán incluir los delimitadores adecuados, ya que no hay ninguna garantía
de que TCP genere un segmento por cada mensaje recibido de la aplicación, TCP puede
tomarse la libertad de agrupar o separar los datos recibidos de la aplicación según le
convenga; por ejemplo, podría decidir agrupar los datos recibidos en varios mensajes de
la aplicación para crear segmentos de tamaño mayor y usar así de manera más eficiente
la red.

5.3.2 Segmentos
La entidad TCP emisora y la receptora intercambian datos en forma de segmentos. Un
segmento consiste en un encabezado TCP fijo de 20 bytes (más una parte opcional)
seguido de cero o más bytes de datos.
El software de TCP decide el tamaño de los segmentos; puede acumular datos de varias
escrituras para formar un segmento, o dividir los datos de una escritura en varios seg-
mentos. Hay dos límites que restringen el tamaño de segmento. Primero, cada
segmento, incluido el encabezado TCP, debe caber en la carga útil de 65,515 bytes del
IP. Segundo, cada red tiene una unidad máxima de transferencia (MTU) y cada
segmento debe caber en la MTU. En la prácti- ca, la MTU es, generalmente, de 1500
bytes (el tamaño de la carga útil en Ethernet) y, por tanto, define el límite superior del
tamaño de segmento.
El protocolo básico usado por las entidades TCP es el protocolo de ventana corrediza.
Cuando un transmisor envía un segmento, también inicia un temporizador. Cuando llega
el segmento al destino, la entidad TCP receptora devuelve un segmento (con datos, si
existen, de otro modo sin ellos) que contiene un número de confirmación de recepción
igual al siguiente número de secuencia que espera recibir. Si el temporizador del emisor
expira antes de la recepción de la confirmación, el emisor envía de nuevo el segmento.
Aunque este protocolo suena sencillo, tiene muchos vericuetos que explicaremos a
continuación. Por ejemplo, pueden llegar segmentos fuera de orden, por lo que los bytes
3072−4095 podrían llegar pero no enviarse confirmación de recepción porque los bytes
2048−3071 no han aparecido aún. También pueden retardarse segmentos en tránsito
durante tanto tiempo que el temporizador del emisor expira y los segmentos se
retransmiten. Las retransmisiones podrían incluir rangos de bytes diferentes a los de la
transmisión original, lo cual requiere una administración cuidadosa para llevar el control
de los bytes que se han recibido correctamente en un momento determinado. Sin
embargo, esto es factible ya que cada byte del flujo tiene su propio desplazamiento
único.
Cada segmento comienza con un encabezado de formato fijo de 20 bytes. El encabezado
fijo puede ir seguido de opciones de encabezado. Tras las opciones, si las hay, pueden
continuar hasta 65,535 − 20 − 20 = 65,495 bytes de datos, donde los primeros 20 se
refieren al encabezado IP y los segundos al encabezado TCP. Los segmentos sin datos
son legales y se usan por lo común para confirmaciones de recep- ción y mensajes de
control.

Encabezado TCP
Realicemos la disección del encabezado TCP campo por campo. Los campos
de Número de secuencia y Número de confirmación de recepción desempeñan sus
funciones normales. Nótese que el segundo especifica el siguiente byte esperado, no el
último byte correctamente recibido. Ambos tienen 32 bits de longitud porque cada byte
de datos está numerado en un flujo TCP.
La Longitud del encabezado TCP indica la cantidad de palabras de 32 bits contenidas en
el encabezado TCP. Esta información es necesaria porque el campo de Opciones es de
longitud variable, por lo que el encabezado también. Técnicamente, este campo en
realidad indica el comienzo de los datos en el segmento, medido en palabras de 32 bits,
pero ese número es simplemente la longitud del encabezado en palabras, por lo que el
efecto es el mismo.
A continuación viene un campo de 6 bits que no se usa. El que este campo haya
sobrevivido intacto durante más de una década es testimonio de lo bien pensado que
está el TCP.
Ahora vienen seis indicadores de 1 bit, de los cuales mencionaremos dos, el PUSH y
URGENT.
Para poder enviar datos prioritarios y responder ante situaciones urgentes TCP dispone
de dos mecanismos extraordinarios por los que las aplicaciones le pueden indicar su
deseo de enviar rápidamente datos al otro extremo.
5.3.3 Push
El bit PSH indica datos que se deben transmitir de inmediato. Por este medio se solicita
atentamente al receptor que entregue los datos a la aplicación a su llegada y no los
almacene en búfer hasta la recepción de un búfer completo (lo que podría hacer en otras
circunstancias por razones de eficiencia), este indicador se utiliza por ejemplo cuando
en una sesión Telnet el usuario pulsa la tecla ―return‖, o cuando en una trasferencia FTP
se envía el último segmento; en estos casos si no se utilizara PSH se correría el riesgo
de que TCP se quedara esperando más datos de la aplicación para así construir un
segmento mayor y usar la red de manera mas eficiente.
5.3.4 Datos Urgentes
URG se establece en 1 se está en uso el apuntador urgente. El apuntador urgente sirve
para indicar un desplazamiento en bytes a partir del número actual de secuencia en el
que se encuentran datos urgentes. Este recurso sustituye los mensajes de interrupción.
Como se mencionó antes, este recurso es un mecanismo rudimentario para permitir que
el emisor envíe una señal al receptor sin implicar al TCP en la razón de la interrupción.
Por ejemplo en una sesión telnet se utiliza este procedimiento para enviar los caracteres
DEL, CTRL-C, o cuando se pulsa la tecla BREAK o ATTN. En estos casos no solo se
desea enviar cuanto antes los caracteres recién tecleados, sino que se quiere que estos
pasen por delante de cualesquiera otros que hubiera pendientes de enviar a la aplicación
y se le entreguen a ésta sin esperar a que los solicite (por ejemplo para abortar una

ejecución en marcha cuando ésta no espera leer datos). Cuando un segmento contiene
datos urgentes se indica esta condición mediante un bit indicador (flag) especial.
5.3.5 Puertos de Aplicación
Los campos de Puerto de origen y Puerto de destino identifican los puntos terminales
locales de la conexión. Los puertos bien conocidos se especifican
en http://www.iana.org pero cada host puede asignar los demás según sea necesario.
5.3.6 Direcciones de Conectores
La dirección de un puerto más la dirección IP de su host forman un punto terminal
único de 48 bits. Los puntos terminales de origen y de destino en conjunto identifican la
conexión.
5.4 Mecanismos de Fiabilidad de TCP
El control de flujo en el TCP se maneja usando una ventana corrediza de tamaño
variable. El campo Tamaño de ventana indica la cantidad de bytes que pueden enviarse
comenzando por el byte cuya recepción se ha confirmado. Es válido un campo
de Tamaño de ventana de 0, e indica que se han recibido los bytes hasta Número de
confirmación de recepción − 1, inclusive, pero que el receptor actualmente necesita un
descanso y quisiera no recibir más datos por el momento, gracias. El permiso para
enviar puede otorgarse después enviando un segmento con el mismo Número de
confirmación de recepción y un campo Tamaño de ventana distinto de cero.
En TCP, las confirmaciones de recepción y los permisos para enviar datos adicionales
son completamente independientes. En efecto, un receptor puede decir: ―He recibido
bytes hasta k, pero por ahora no deseo más‖. Esta independencia (de hecho, una ventana
de tamaño variable) da flexibilidad adicional. Más adelante lo estudiaremos con más
detalle.
También se proporciona una Suma de verificación para agregar confiabilidad. Es una
suma de verificación del encabezado, los datos y el pseudoencabezado conceptual
mostrado en la figura 6-30. Al realizar este cálculo, se establece el campo de Suma de
verificación del TCP en cero, y se rellena el campo de datos con un byte cero adicional
si la longitud es un número impar. El algo- ritmo de suma de verificación simplemente
suma todas las palabras de 16 bits en complemento a 1 y luego obtiene el complemento
a 1 de la suma. Como consecuencia, al realizar el cálculo el receptor con el segmento
completo, incluido el campo de Suma de verificación, el resultado debe ser 0.
El pseudoencabezado contiene las direcciones IP de 32 bits de las máquinas de origen y
de destino, el número de protocolo de TCP (6), y la cuenta de bytes del segmento TCP
(incluido el encabezado). La inclusión del pseudoencabezado en el cálculo de la suma
de verificación TCP ayu- da a detectar paquetes mal entregados, pero hacerlo viola la
jerarquía de protocolos puesto que las direcciones de IP que contiene pertenecen a la
capa IP, no a la capa TCP. UDP utiliza el mismo pseudoencabezado para su suma de
verificación.

El campo Opciones ofrece una forma de agregar características extra no cubiertas por el
encabezado normal. La opción más importante es la que permite que
cada host especifique la carga útil TCP máxima que está dispuesto a aceptar. El uso de
segmentos grandes es más eficiente que el de segmentos pequeños, puesto que el
encabezado de 20 bytes puede entonces amortizarse entre más datos, pero
los hosts pequeños tal vez no puedan manejar segmentos muy grandes.
Pseudoencabezado incluido en la suma de verificación del TCP.
Durante el establecimiento de la conexión, cada lado puede anunciar su máximo y ver el
de su compañero. Si un host no usa esta opción, tiene una carga útil predeterminada de
536 bytes. Se requiere que todos los hosts de Internet acepten segmentos TCP de 536 +
20 = 556 bytes. No es necesario que el tamaño máximo de segmento en ambas
direcciones sea el mismo.
En las líneas con alto ancho de banda, alto retardo o ambas cosas, la ventana de 64 KB
con frecuencia es un problema. En una línea T3 (44.736 Mbps) se requieren sólo 12
mseg para enviar una ventana completa de 64 KB. Si el retardo de propagación de ida y
vuelta es de 50 mseg (típico de una fibra transcontinental), el emisor estará inactivo 3/4
del tiempo en espera de confirmaciones de recepción. En una conexión satelital la
situación es peor aún. Un tamaño de ventana más grande permitirá al emisor continuar
enviando datos, pero como el campo de Tamaño de ventana es de 16 bits, es imposible
expresar tal tamaño. En el RFC 1323 se propuso una opción de escala de ventana que
permite al emisor y al receptor negociar un factor de escala de ventana. Este nú- mero
da la posibilidad de que ambos lados desplacen el campo de Tamaño de ventana hasta
14 bits a la izquierda, permitiendo por tanto ventanas de hasta 230 bytes. La mayoría de
las implementa- ciones actuales de TCP manejan esta opción.
Otra opción propuesta en el RFC 1106 y ahora de uso difundido es el empleo de la
repetición selectiva en lugar del protocolo de retroceso n. Si el receptor recibe un
segmento malo y luego una gran cantidad de segmentos buenos, el temporizador del
protocolo TCP normal expirará en algún momento y se retransmitirán todos los
segmentos sin confirmación de recepción, incluidos los que se recibieron correctamente.
El RFC 1106 introdujo los NAKs, para permitir que el receptor solicite un segmento
(o segmentos) específico. Tras recibirlo, puede enviar una confirmación de recepción de
todos los datos que tiene en búfer, reduciendo de esta manera la cantidad de datos
retransmitidos.
CONEXIÓN
La conexión en TCP se lleva a cabo entre 2 procesos de la capa de aplicación,
identificados por un par compuesto de direcciones IP y puertos TCP. Se puede
visualizar como una tubería bidireccional de datos que contiene 2 tuberías lógicas entre

los dos puntos TCP, una se utiliza para salida de datos y el otro para entrada (la salida
de datos para un punto TCP es la entrada del otro).
Las conexiones TCP son:
Establecidas a través de un proceso llamado ―handshake‖ en el cual ambos
puntos TCP aceptan crear la conexión
Mantenidas opcionalmente a través de un proceso periódico que asegura que
ambos puntos están activos en la conexión
Terminadas por otro proceso ―handshake‖ si ambos puntos TCP acuerdan
terminar la conexión
5.5 Establecimiento de la Conexión
Para crear una conexión y que los datos comiencen a fluir, cada par TCP debe obtener la
siguiente información del otro par:
El número de la secuencia de arranque para los datos enviados en la tubería de
entrada.
La cantidad máxima de datos que pueden ser enviados al tubo de salida antes de
esperar un reconocimiento (el tamaño de la ventana a recibir de otro par TCP).
El tamaño máximo del segmento (MSS) que se puede recibir.
Las opciones TCP soportadas.
Ésta información es averiguada a través de un intercambio de 3 segmentos TCP
llamados procesos de establecimiento de conexión TCP, o TCP ―handshake‖ de 3 vías.
Para crear una conexión, un par TCP que escucha debe permitir la conexión, y el otro
par debe iniciar la conexión. El par TCP que escucha utiliza una función pasiva OPEN
para permitir las conexiones entrantes requeridas en un puerto específico. El par que
inicia usa la función activa OPEN la cual crea y envía el primer segmento del
―handshake‖ de 3 vías.
1. El par TCP 1 inicializa con su número de secuencia (ISN1), ack = 0, ventana por
default, un segmento de sincronización, la escala de la ventana TCP y algunas
opciones.
2. El par TCP 2 envía un segmento de sincronización y reconocimiento, su número
de secuencia (ISN2), ventana por default, la escala de la ventana, ack = ISN1 +1
y algunas opciones.
3. El par TCP 1 envía un reconocimiento, su número de secuencia +1, ack = ISN2
+1 y tamaño de la ventana por default.
El segmento sincronizado (SYN)
El par TCP 1 envía el primer segmento TCP, conocido como el segmento SYN al par 2.
Este segmento establece los parámetros de conexión, así como como el número de
secuencia inicial (ISN) que el par TCP 1 utiliza.
El segmento SYN enviado por una computadora corriendo Windows Server 2008 o
Windows Vista contiene los siguientes campos en el encabezado TCP:

Puerto destino (típicamente un puerto en el rango del 1 al 1023).
Puerto de origen (puerto asignado dinámicamente).
Número de secuencia (establece en el ISN que los datos del par TCP 1 sean
enviados por el canal de datos de salida).
Número de reconocimiento (puesto a 0 porque la bandera ACK no se ha
establecido, por lo que no es significante aún).
Bandera SYN (indica que el segmento contiene el ISN para envío de datos por el
par TCP 1).
Ventana (indica la cantidad máxima inicial del tamaño de datos que el par TCP 1
puede recibir).
MSS (tamaño máximo del segmento TCP que el par TCP 1 puede recibir).
Factor de escala de la ventana.
El segmento SYN-ACK
Después de recibir el segmento SYN, el par TCP 2 envía el segundo segmento (SYN-
ACK) al par 1. Este segmento establece los parámetros de conexión que utiliza el par 2,
así como el ISN y reconoce los parámetros de conexión usados por el par 1. Su
encabezado TCP contiene:
Puerto destino.
Puerto de origen.
Número de secuencia.
Número de reconocimiento (valor ISN del par TCP 1 +1).
Bandera SYN (indica que el segmento contiene el ISN para datos enviados por
el par TCP 2).
Bandera ACK (indica si el campo del número de reconocimiento es
significante).
Ventana (indica la cantidad máxima inicial del tamño de datos que el par TCP 2
puede recibir).
MSS (tamaño máximo del segmento TCP que puede recibir el par TCP 2)
Factor de escala de la ventana.
El segmento ACK
Después de recibir el segmento SYN-ACK, el par TCP 1 envía el tercer segmento al
par 2. Establece los parámetros finales de conexión utilizados por el par 1 y reconoce
los parámetros de conexión que utiliza el par 2. Contiene los siguientes campos en su
encabezado TCP:
Puerto destino.
Puerto de origen.
Número de secuencia (ISN1 +1).
Número de reconocimiento (valor ISN del par TCP 2 +1).
Bandera ACK (indica si el campo del número de reconocimiento es
significante).
Ventana.
Resultados de la Conexión

Intercomunicacion y seguridad en redes

Intercomunicacion y seguridad en redes

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Intercomunicacion y seguridad en redes

Similaire à Intercomunicacion y seguridad en redes (20)

Intercomunicacion y seguridad en redes