Resumen del Libro

TCP / IP
De Douglas Comer
2do Parcial Redes II

Incluye temas adicionales

ndice
21 ARRANQUE Y AUTOCONFIGURACIN (BOOTP Y DHCP).................................6
21.1 INTRODUCCIN.......................................................................................................... 6
21.2 LA NECESIDAD DE UNA ALTERNATIVA A RARP...................................................................6
21.3 UTILIZACIN DE IP PARA DETERMINAR UNA DIRECCIN IP...................................................6
21.4 POLTICA DE RETRANSMISIN BOOTP.............................................................................6
21.5 FORMATO DE LOS MENSAJES BOOTP..............................................................................7
21.6 PROCEDIMIENTO DE ARRANQUE EN DOS PASOS.................................................................7
21.7 CAMPO DE REA DE VENDEDOR ESPECIFICO.....................................................................7
21.8 LA NECESIDAD DE UNA CONFIGURACIN DINMICA.............................................................7
21.9 CONFIGURACIN DINMICA DE ANFITRIN........................................................................8
21.10 ASIGNACIN DINMICA DE DIRECCIONES IP....................................................................8
21.11 OBTENCIN DE DIRECCIONES MLTIPLES........................................................................8
21.12 ESTADOS DE ADQUISICIN DE DIRECCIONES...................................................................8
21.13 TERMINACIN TEMPRANA DE ARRENDAMIENTO................................................................9
21.14 ESTADO DE RENOVACIN DE ARRENDAMIENTO................................................................9
21.15 FORMATO DE LOS MENSAJES DHCP............................................................................10
21.16 OPCIONES Y TIPOS DE MENSAJES DHCP......................................................................10
21.17 OPCIN OVERLOAD................................................................................................. 10
21.18 DHCP Y NOMBRES DE DOMINIOS...............................................................................10
22 SISTEMA DE NOMBRE DE DOMINIO (DNS).................................................11
22.1 INTRODUCCIN........................................................................................................ 11
22.2 NOMBRES PARA LAS MQUINAS....................................................................................11
22.3 ESPACIO DE NOMBRE PLANO.......................................................................................11
22.4 NOMBRES JERRQUICOS.............................................................................................11
22.5 DELEGAR AUTORIDAD PARA LOS NOMBRES.....................................................................11
22.6 AUTORIDAD PARA SUBCONJUNTOS DE NOMBRES..............................................................11
22.7 NOMBRES DE DOMINIO TCP/IP....................................................................................12
22.8 NOMBRES DE DOMINIO OFICIALES Y NO OFICIALES...........................................................12
22.9 COSAS POR NOMBRAR Y SINTAXIS DE LOS NOMBRES........................................................13
22.10 ASOCIACIN DE NOMBRES DE DOMINIO EN DIRECCIONES.................................................14
22.11 RESOLUCIN DE NOMBRES DE DOMINIO.......................................................................15
22.12 TRADUCCIN EFICIENTE........................................................................................... 15
22.13 DESEMPEO DEL CACHE: LA CLAVE DE LA EFICIENCIA.....................................................15
22.14 FORMATO DE LOS MENSAJES DEL SERVIDOR DE DOMINIOS...............................................15
22.15 FORMATO DEL NOMBRE COMPRIMIDO..........................................................................15
22.16 ABREVIATURA DE NOMBRES DE DOMINIO......................................................................15
22.17 ASOCIACIONES INVERSAS.........................................................................................16
22.18 BSQUEDAS DE APUNTADOR.....................................................................................16
22.19 TIPOS DE OBJETOS Y CONTENIDO DEL REGISTRO DE RECURSOS........................................16
22.20 OBTENCIN DE AUTORIDAD PARA UN SUBDOMINIO.........................................................16
23 APLICACIONES: ACCESO REMOTO............................................................17
23.2
23.3
23.4
23.5
23.6
23.7
23.8
23.9

COMPUTACIN REMOTA INTERACTIVA.............................................................................17

PROTOCOLO TELNET...............................................................................................17
ADAPTARSE A LA HETEROGENEIDAD..............................................................................18
TRANSFERENCIA DE COMANDOS QUE CONTROLAN EXTREMO REMOTO..................................18
FORZAR AL SERVIDOR A LEER UNA FUNCIN DE CONTROL.................................................19
OPCIONES DE TELNET.............................................................................................. 19
NEGOCIACIN DE OPCIONES DE TELNET......................................................................19
RLOGIN (BSD DE UNIX)........................................................................................... 19

24 APLICACIONES: TRANSFERENCIA Y ACCESO DE ARCHIVOS.........................20

24.2
24.3
24.4
24.6
24.7
24.8

ACCESO Y TRANSFERENCIA DE ARCHIVOS.......................................................................20

ACCESO COMPARTIDO EN LNEA...................................................................................20
COMPARTIR MEDIANTE TRANSFERENCIA DE ARCHIVOS.......................................................20
CARACTERSTICAS DE FTP..........................................................................................20
MODELO DE PROCESO FTP.........................................................................................21
ASIGNACIN DE NMEROS DE PUERTO..........................................................................21

24.10
24.11
24.12
24.13
24.14
24.15
24.16
24.17

EJEMPLO DE UNA SESIN CON FTP ANNIMO...............................................................21

TFTP................................................................................................................... 22
NFS.................................................................................................................... 22
IMPLANTACIN NFS................................................................................................ 22
LLAMADA DE PROCEDIMIENTO REMOTO (RPC)..............................................................23
RPC PORT MAPPER................................................................................................23
SERVICIOS, PUERTOS Y PROCESOS.............................................................................24
EL PROCESO PORTMAP............................................................................................. 25

25 APLICACIONES: CORREO ELECTRNICO....................................................26

25.2 CORREO ELECTRNICO..............................................................................................26
25.3 NOMBRES Y ALIAS DE LOS BUZONES DE CORREO.............................................................26
25.4 EXPANSIN DE ALIAS Y DIRECCIONAMIENTO DE CORRESPONDENCIA.....................................26
25.5 RELACIN ENTRE EL ENLACE DE REDES Y EL CORREO ELECTRNICO....................................27
25.6 ESTNDARES TCP/IP PARA EL SERVICIO DE CORREO ELECTRNICO......................................27
25.7 DIRECCIONES DE CORREO ELECTRNICO........................................................................28
25.8 PSEUDO DIRECCIONES DE DOMINIO..............................................................................28
25.9 PROTOCOLO DE TRANSFERENCIA DE CORREO SIMPLE (SMTP)............................................28
25.10 LA EXTENSIN MIME PARA DATOS NO ASCII...............................................................29
25.11 MENSAJES MIME MULTIPART.....................................................................................30
25.12 EL COMANDO TURN............................................................................................... 30
28 SEGURIDAD DE INTERNET Y DISEO DEL MURO DE SEGURIDAD.................31
28.1 INTRODUCCIN........................................................................................................ 31
28.2 RECURSOS DE PROTECCIN........................................................................................31
28.3 NECESIDAD DE UNA POLTICA DE INFORMACIN...............................................................31
28.4 COMUNICACIN, COOPERACIN Y DESCONFIANZA MUTUA..................................................32
28.5 MECANISMOS PARA LA SEGURIDAD DE INTERNET.............................................................32
28.5.1 Mecanismos de autenticacin..................................................................................32
28.5.2 Mecanismos de privacidad......................................................................................32
28.6 FIREWALLS Y ACCESO A INTERNET................................................................................33
28.7 CONEXIONES MLTIPLES Y VNCULOS MS DBILES...........................................................33
28.8 IMPLANTACIN DE FIREWALL Y HARDWARE DE ALTA VELOCIDAD...........................................34
28.9 FILTROS DE NIVEL DE PAQUETES...................................................................................34
28.10 ESPECIFICACIN DE SEGURIDAD Y DE FILTRO DE PAQUETES..............................................34
28.11 CONSECUENCIA DEL ACCESO RESTRINGIDO PARA CLIENTES..............................................34
28.12 ACCESO A SERVICIOS A TRAVS DE UN FIREWALL...........................................................35
28.13 DETALLES DE LA ARQUITECTURA DE UN FIREWALL..........................................................35
28.15 IMPLANTACIN ALTERNATIVA DE UN FIREWALL...............................................................36
28.16 MONITOREO Y ESTABLECIMIENTO DE CONEXIN.............................................................36
29 EL FUTURO DE TCP/IP..............................................................................37
29.2 POR QU CAMBIAR TCP/IP E INTERNET?......................................................................37
29.2.1 Nuevas tecnologas de comunicacin y computacin......................................................37
29.2.2 Nuevas aplicaciones.............................................................................................. 37
29.2.3 Incrementos en el tamao y en la carga......................................................................37
29.2.4 Nuevas polticas................................................................................................... 37
29.3 MOTIVOS PARA EL CAMBIO DEL IPV4............................................................................37
29.4 EL CAMINO HACIA UNA NUEVA VERSIN DEL IP...............................................................37
29.5 NOMBRE DEL PRXIMO IP..........................................................................................37
29.6 CARACTERSTICAS DEL IPV6.......................................................................................38
29.8 FORMA GENERAL DE UN DATAGRAMA IPV6.....................................................................38
29.8 FORMATO DEL ENCABEZADO BASE DEL IPV6..................................................................38
29.9 ENCABEZADOS DE EXTENSIN IPV6.............................................................................39
29.10 ANLISIS DE UN DATAGRAMA IPV6.............................................................................39
29.11 FRAGMENTACIN Y RE ENSAMBLAJE DEL IPV6...............................................................39
29.12 CONSECUENCIA DE LA FRAGMENTACIN DE EXTREMO A EXTREMO.....................................39
29.13 RUTEO DE ORIGEN DEL IPV6....................................................................................40
29.14 OPCIONES DEL IPV6............................................................................................... 40
29.15 TAMAO DEL ESPACIO DE DIRECCIN DEL IPV6............................................................40
29.16 NOTACIN HEXADECIMAL CON DOS PUNTOS DEL IPV6...................................................40
29.17 TRES TIPOS BSICOS DE DIRECCIONES IPV6................................................................41

29.18
29.19
29.20
29.21
29.22
29.23

DUALIDAD DE DIFUSIN Y MULTIDIFUSIN....................................................................41

UNA ELECCIN DE INGENIERA Y DIFUSIN SIMULADA.....................................................41
ASIGNACIN PROPUESTA DE ESPACIO DE DIRECCIN IPV6...............................................42
CODIFICACIN Y TRANSICIN DE LA DIRECCIN IPV4.....................................................42
PROVEEDORES, SUSCRIPTORES Y JERARQUA DE DIRECCIONES..........................................42
JERARQUA ADICIONAL.............................................................................................. 42

APNDICE 1 IPSEC.......................................................................................43
A.1.1 QU ES IPSEC?..................................................................................................... 43
A.1.2 LOS PROTOCOLOS IPSEC...........................................................................................43
A.1.2.1 Cabecera de autenticacin AH................................................................................43
A.1.2.2 Carga de Seguridad Encapsulada ESP......................................................................44
APNDICE 2 PROTOCOLO IKE........................................................................46
A.2.1 PARA QUE SIRVE IKE?............................................................................................46
A.2.2 CARACTERSTICAS DE IKE.........................................................................................46
A.2.3 FASES DE IKE......................................................................................................... 46
APNDICE 3 NAT..........................................................................................47
A.3.1 QU ES NAT?....................................................................................................... 47
A.3.2 FUNCIONAMIENTO.................................................................................................... 47
A.3.2.1 Esttico............................................................................................................ 47
A.3.2.2 Dinmico.......................................................................................................... 47
A.3.2.3 Sobrecarga........................................................................................................ 48
A.3.2.4 Solapamiento..................................................................................................... 48
APNDICE 4 HTTP........................................................................................49
A.4.1
A.4.2
A.4.3
A.4.4
A.4.5
A.4.6
A.4.7
A.4.8
A.4.9

QUE ES HTTP?....................................................................................................... 49
EL PROTOCOLO SEGN LAS VERSIONES........................................................................49
CARACTERSTICAS DEL PROTOCOLO.............................................................................49
DEFINICIONES RELACIONADAS CON EL PROTOCOLO.........................................................49
SISTEMAS INTERMEDIOS............................................................................................ 50
MTODOS DE PETICIN EXISTENTES.............................................................................50
IDENTIFICACIN DE RECURSOS...................................................................................51
MENSAJES DE RESPUESTA..........................................................................................51
CABECERAS HTTP................................................................................................... 51

APNDICE 5 PAT..........................................................................................52
A.5.1 QU ES PAT?....................................................................................................... 52
A.5.2 PROCEDIMIENTO PAT............................................................................................... 52
APNDICE 6 BGP..........................................................................................53
A.6.1 INTRODUCCIN....................................................................................................... 53
A.6.2 FUNCIONES DE BGP................................................................................................ 53
A.6.3 MENSAJES DE BGP..................................................................................................53
A.6.4 PROCEDIMIENTOS FUNCIONALES DE BGP......................................................................53
A.6.4.1 Adquisicin de vecino........................................................................................... 54
A.6.4.2 Deteccin de vecino alcanzable...............................................................................54
A.6.4.3 Deteccin de red alcanzable...................................................................................54
APNDICE 7 RSVP........................................................................................55
A.7.1
A.7.2
A.7.3
A.7.4

QU ES RSVP?..................................................................................................... 55
CARACTERSTICAS DE RSVP......................................................................................55
QU ES EL SOFT STATE?.........................................................................................55
LOS MENSAJES DE RSVP.......................................................................................... 55

REFERENCIAS.............................................................................................. 56
ACRNIMOS................................................................................................ 57

21 Arranque y autoconfiguracin (BOOTP y DHCP)

21.1 Introduccin
Una mquina necesita de cierta informacin para poder transmitir, como por ejemplo la
direccin de un router, su propia direccin IP, la mscara de red en uso, etc.
Estos dos protocolos son una alternativa a RARP. Utilizan un esquema cliente/servidor y
trabajan sobre UDP como protocolo de transporte.

21.2 La necesidad de una alternativa a RARP

Una mquina sin disco, posee un pequeo programa de arranque en su memoria no voltil
(ROM). Pero como este cdigo es utilizado en diferentes mquinas, la direccin IP no puede
ser harcodeada en el mismo, por lo tanto una mquina deber obtener su IP (y otra
informacin adicional) desde otra fuente. RARP brinda esta funcionalidad, pero posee tres
problemas:
1. Como es un protocolo de bajo nivel, su uso requiere acceso directo al HW, por tanto
puede resultar muy difcil para un programador implementar un servidor.
2. La respuesta por parte del servidor a una solicitud contiene muy poca informacin
(direccin IP del cliente de 4 bytes) y esto resulta molesto para redes que imponen un
tamao mnimo de paquete.
3. Como RARP utiliza las direcciones fsicas para identificar las mquinas, no puede
usarse en redes de asignacin dinmica de direcciones de HW.
Para sortear estas deficiencias de RARP fue que se present BOOTP (Boot Strip Protocol) y
ms tarde DHCP (Dynamic Host Configuration Protocol) como su sucesor.

21.3 Utilizacin de IP para determinar una direccin IP

La mquina que desea obtener informacin de la red, enva un mensaje en modo difusin (IP
destino 255.255.255.255). Este mensaje es recibido por el servidor quien contestar con la
informacin correspondiente utilizando tambin la difusin, ya que si lo enviara directamente
al solicitante, cuando este reciba el paquete con la informacin, no sabr que es para l ya
que no conoce su propia IP.

21.4 Poltica de retransmisin BOOTP

BOOTP confiere toda la responsabilidad de la confiabilidad de la comunicacin al cliente.
BOOTP requiere que UDP realice sumas de verificacin para protegerse de la alteracin de
datos, ya que IP slo verifica el encabezado IP, y adems que se enve con el bit de no
fragmentacin activado.
Para manejar prdidas se usa la tcnica de temporizador y retransmisin. Los tiempos
elegidos para el timeout son aleatorios, y se duplican despus de cada retransmisin. Esto
sirve para evitar que BOOTP aada un trfico excesivo a la red (aumentar el temporizador) y
para evitar colisiones (tiempos aleatorios).

21.5 Formato de los mensajes BOOTP

Con motivos de tener una implantacin sencilla, los mensajes de ida y vuelta de BOOTP
tienen el mismo formato y poseen campos de longitud fija.
Algunos campos son:

OP: Especifica si se trata de un mensaje de solicitud o respuesta.

HTYPE: Especifica el tipo de hardware de la red.
HLEN: Especifica la longitud de la direccin fsica.

HOPS: Indica la cantidad de veces que la solicitud es reenviada por un servidor

BOOTP a otro servidor BOOTP. Cuando el cliente enva la solicitud, pone este valor
en 0.
SECONDS: Especifica la cantidad de segundos desde que el cliente inici el
arranque.

21.6 Procedimiento de arranque en dos pasos

BOOTP no proporciona una imagen de memoria a los clientes, sino que brinda informacin
necesaria para que los clientes puedan obtenerla. Utilizar un procedimiento de dos pasos
ayuda a mantener separadas las etapas de configuracin y almacenamiento y esto sirve para
permitir al administrador configurar conjuntos de mquinas para que estas acten en forma
idntica.
Ejemplo:
Supongamos un conjunto de estaciones de trabajo en el cual hay diferentes arquitecturas de
HW. Dada la diversidad de arquitecturas, se sabe que una sola imagen de memoria no puede
operar en todas las mquinas, por lo tanto BOOTP otorga un campo llamado BOOT FILE
NAME, para que cada cliente pueda manifestar su preferencia depositando un nombre
genrico (ej.: Unix). El servidor BOOTP luego relaciona ese nombre genrico con el nombre
de archivo buscando en una base de datos de configuracin.
Si el cliente enva el campo en 0, el servidor seleccionar una imagen de manera automtica.
Enviar Unix en el BOOT FILE NAME significa que el cliente dice quiero arrancar el SO
UNIX para esta mquina

21.7 Campo de rea de vendedor especifico

21.8 La necesidad de una configuracin dinmica
Como RARP, BOOTP fue diseado para un ambiente relativamente esttico en el que cada
anfitrin tiene una conexin de red permanente. Un administrador crea un archivo de
configuracin BOOTP para cada mquina que especifica un conjunto de parmetros para
cada anfitrin, y ste permanece relativamente estable dada la baja cantidad de cambios.
Con la llegada de las redes inalmbricas se hizo posible el transporte de una mquina de un
lugar a otro, y BOOTP no se adapta porque es necesario que un administrador agregue
parmetros a cada anfitrin y almacene la informacin en un archivo de configuracin de
servidor BOOTP. BOOTP no admite una forma de asignar dinmicamente valores a
mquinas individuales.

21.9 Configuracin dinmica de anfitrin

Para la asignacin dinmica de direcciones IP, se cre el protocolo DHCP (Dynamic Host
Configuration Protocol) que extiende a BOOTP de dos formas:
1. Permite que una mquina adquiera toda la informacin que necesita con un slo
mensaje.
2. Permite que una computadora posea una direccin IP en forma rpida y dinmica.
Para ser completamente general, DHCP permite tres tipos de configuraciones diferentes:
1. Al igual que BOOTP, DHCP permite la configuracin manual, donde el administrador
puede asignar una direccin especfica para una mquina determinada.
2. Configuracin automtica, mediante la cual el administrador permite a un servidor
DHCP asignar una direccin automtica a una computadora que es conectada por
primera vez a la red.
6

3. Configuracin dinmica. El servidor presta una direccin para una computadora

por tiempo limitado.
Un servidor DHCP puede configurarse para asignar direcciones estticas a ciertas mquinas y
direcciones dinmicas a otras.

21.10 Asignacin dinmica de direcciones IP

La asignacin dinmica no es una transformacin uno a uno, y el servidor no necesita
conocer la identidad del cliente a priori.
Como el DHCP permite a un anfitrin obtener todos los parmetros necesarios
para la comunicacin, sin la intervencin manual, tambin permite la
autoconfiguracin, la cual se encuentra sujeta a restricciones administrativas.
Para hacer posible la autoconfiguracin un servidor DHCP comienza con un conjunto de
direcciones IP que el administrador de red asigna al servidor para su manejo, adems de las
reglas bajo las que opera el servidor. Cuando se produce un intercambio el servidor
proporciona una direccin al cliente, el cliente chequea la IP y si es aceptable ya puede
comenzar a usarla. Esta asignacin, a diferencia de la asignacin esttica, tiene un
determinado tiempo de validez. Ese tiempo lo establece el servidor en el momento de la
asignacin. Cuando se vence ese tiempo, el cliente debe renovar la direccin o dejar de
usarla.
El tiempo de arrendamiento de las direcciones puede variar dependiendo del propsito de la
red. Para adaptarse a todos los ambientes, DHCP no especifica un periodo fijo sino que
permite que el cliente solicite un determinado tiempo y que el servidor le comunique que ese
tiempo ha sido garantizado. As el administrador puede decidir durante cunto tiempo podr
asignar un servidor una direccin a un cliente.

21.11 Obtencin de direcciones mltiples

21.12 Estados de adquisicin de direcciones
Un cliente puede estar en alguno de los siguientes 6 estados:
1. INITIALIZE: Cuando el cliente arranca por primera vez.
2. SELECT: Este estado es seteado luego de que el cliente envi el mensaje
DHCPDISCOVER (este mensaje es enviado en un datagrama UDP con el
puerto de destino activado para el puerto BOOTP). Los servidores que estn
configurados para responder, responden con un mensaje DHCPOFFER.
Mientras el cliente est en estado SELECT, recolecta dichas respuestas.
3. REQUEST: Una vez que el cliente selecciona una de las respuestas enviadas y
negocia el tiempo de arrendamiento, enva un mensaje DHCPREQUEST y entra
en este estado.
4. BOUND: Con fin de enviar un acuse de recibo, el servidor contesta la solicitud
con un mensaje DHCPACK. Cuando el cliente lo recibe cambia su estado a
BOUND, en el cual el cliente pasa a usar la direccin obtenida. Este estado sera
el estado normal de operacin.
5. RENEW: Se alcanza cuando un cliente en estado BOUND enva un mensaje
DHCPREQUEST porque ha caducado el temporizador que controla la
renovacin. En ese mensaje viaja la direccin IP del cliente.
6. REBIND: Cuando un cliente envi un mensaje DHCPREQUEST y no hay una
respuesta por parte del servidor, el cliente lo considera inactivo. Cuando el
temporizador que controla la reasignacin (este se setea cuando el cliente entra
en el estado BOUND y tiene un valor por defecto del 87.5% del valor de
arrendamiento) caduca, el cliente pasa al estado REBIND y comienza a difundir
mensajes DHCPREQUEST.
7

21.13 Terminacin temprana de arrendamiento

Sirve para cuando un cliente quiere terminar su arrendamiento sin tener que esperar a que ese
tiempo expire. Es especialmente til cuando el nmero de mquinas es ms elevado que el
nmero de direcciones IP disponibles, ya que los clientes que consideren que no necesitan la
IP que tienen asignada, pueden liberarla para que otras mquinas la utilicen.
Para terminar un arrendamiento de manera temprana, el cliente enva un mensaje
DHCPRELEASE. Liberar una direccin es una accin final que previene que el cliente
contine utilizando la direccin, as, luego de transmitir el mensaje de liberacin, el cliente
no debe enviar ningn otro datagrama que utilice la direccin IP.
Cuando el mensaje DHCPRELEASE es enviando, el cliente pasa del estado BOUND al
estado INITIALIZE.

21.14 Estado de renovacin de arrendamiento

Cuando un cliente adquiere el estado BOUND, inicia 3 temporizadores que controlan:
1. La renovacin de arrendamiento
2. La reasignacin de arrendamiento
3. La expiracin de arrendamiento
El servidor puede determinar valores para estos temporizadores, pero en caso de que no lo
haga, el cliente asignar valores por omisin. El valor para el temporizador de renovacin
ser la mitad del tiempo de arrendamiento.
Cuando se vence el tiempo de renovacin, el cliente pasa al estado RENEW y enva un
mensaje DHCPREQUEST con su IP y espera una respuesta por parte del servidor. El
servidor puede responder de dos formas:
1. Puede instruir al cliente para que deje de usar la IP enviando DHCPNACK, lo cual
obliga al cliente a volver a su estado INITIALIZE.
2. Puede aprobar que siga usando su IP actual enviando un DHCPACK. En este mensaje
pueden viajar nuevos valores de temporizacin.
Si el servidor no responde (por estar inactivo o inaccesible para el cliente) el cliente pasar al
estado REBIND en el momento en que se venza el temporizador de reasignacin (este posee
un valor por defecto de un 87.5% del tiempo de arrendamiento) y comienza a difundir
mensajes DHCPREQUEST. Cualquier servidor habilitado para responder, puede hacerlo de
manera positiva o negativa. Si la respuesta es positiva, el cliente pasa nuevamente al estado
BOUND (en esa respuesta pueden enviarse nuevos valores de temporizacion). Si la respuesta
es negativa el usuario deber dejar de utilizar la direccin IP inmediatamente.
Si estando en REBIND ningn servidor contesta los DHCPREQUEST del cliente, este
ltimo pasar al estado INITIALIZE (para comenzar nuevamente la obtencin de una IP) una
vez que haya vencido el tercer temporizador (el que controla la expiracin).

21.15 Formato de los mensajes DHCP

El formato de los mensajes DHCP es muy similar al de los mensajes BOOTP, de hecho, los
protocolos son compatibles. Hay algunas diferencias en la interpretacin de algunos campos,
como por ejemplo el campo UNUSED de BOOTP que en DHCP se llama FLAGS y se usa
para que el cliente pueda informarle al servidor si quiere que este ltimo responda realizando
una unidifusin o una multidifusin por HW.

21.16 Opciones y tipos de mensajes DHCP

21.17 Opcin Overload
Los campos SERVER HOST NAME y BOOT FILE NAME en el encabezado BOOTP
ocupan mucho espacio, entonces si un mensaje no contiene informacin en estos campos,
DHCP posee una Option Overload para que los campos puedan ser sobrecargados e indica al
8

receptor si debe ignorar el significado usual de estos campos y considerar las opciones con
las que se sobrecarg.

21.18 DHCP y nombres de dominios

22 Sistema de nombre de dominio (DNS)

22.1 Introduccin
22.2 Nombres para las mquinas
22.3 Espacio de nombre plano
Se denomina espacio de nombre plano al conjunto original de nombres usados a travs de
Internet formado por una secuencia de caracteres que no contiene ninguna estructura
adicional. Estos nombres eran administrados por la NIC (Network Information Center) que
luego fue reemplazado por la INTERNIC. (Internet Network Information Center).
Ventajas:
Nombres convenientes y cortos
Desventajas:
El espacio de nombres no puede generalizarse para conjuntos grandes de mquinas.
Mucho trfico en la nica entidad administradora.
Poca adaptabilidad para el crecimiento rpido.

22.4 Nombres jerrquicos

Se cre para la descentralizacin del mecanismo de asignacin de nombres, delegando la
autoridad del espacio de nombres y repartiendo la responsabilidad de traduccin de nombres.
La estructura elegida es una estructura de rbol invertido.

22.5 Delegar autoridad para los nombres

El espacio de nombres es particionado y la autoridad para los nombres de las subdivisiones
pasa a agentes designados.
Ejemplo:
local.localidad
La autoridad central autoriza a la localidad localidad a administrar una determinada particin
de nombres. En el ejemplo, local es la parte del nombre controlado por localidad.
Cuando la mxima autoridad aade una nueva localidad X, la aade a la lista de localidades
vlidas y delega a X la autoridad sobre todos los nombres que terminen con .X

22.6 Autoridad para subconjuntos de nombres

En el espacio jerrquico de nombres, la autoridad puede subdividirse en cada nivel. La idea
es subdividir tanto como sea necesario para que las subdivisiones sean manejables.
Sintcticamente, cada vez que se subdivide el espacio de nombres, se introduce una nueva
particin del nombre.
Ejemplo:
local.grupo.localidad
La localidad localidad delega autoridad a grupo, por lo tanto podr haber nombres distintos o
no de grupos para las diferentes localidades.
Ejemplo:
produccin.grupo1.localidad1
produccin.grupo1.localidad2
produccin.grupo2.localidad1
En una red de redes TCP/IP, la jerarqua de nombres de mquina se asigna de
acuerdo con la estructura de la organizacin que obtiene la autoridad para dividir
10

el espacio de nombres y no necesariamente de acuerdo con la estructura de las

interconexiones de red fsica.
En una universidad puede pasar que dos departamentos diferentes compartan fsicamente las
mismas instalaciones de red, pero pueden tener lneas de autoridad diferentes dentro de la
misma.

22.7 Nombres de dominio TCP/IP

El mecanismo que implanta una jerarqua de nombres para la red de redes TCP/IP se llama
DNS (Domain Name System) y tiene dos aspectos independientes:
1. Es abstracto. Especifica la sintaxis del nombre y las reglas para delegar autoridad de
los nombres.
2. Es concreto. Dice como se implementa el sistema distribuido que transforma los
nombres en direcciones IP.
El sistema de nombres de dominio llama a cada componente del nombre (separados por
punto) etiqueta, por lo tanto el siguiente ejemplo posee tres etiquetas:
cs.purdue.edu

cs: Este dominio corresponde al departamento de ciencias Computacionales de la

Universidad de Purdue.
purdue: Es el nombre de dominio para la Universidad de Purdue.
edu: Es el nombre de dominio para las instituciones educativas.

22.8 Nombres de dominio oficiales y no oficiales

El sistema de dominio dicta slo la forma de los nombres y no sus valores, por lo tanto es
posible, para cualquier grupo que constituya una instancia del dominio seleccionar etiquetas
para todas las partes de su jerarqua.
Sin embargo la mayora de los usuarios de tecnologa de dominio sigue la jerarqua de
etiquetas usada por el sistema de dominio oficial de Internet por dos razones:
1. El esquema de Internet es completo y flexible y se adapta a una amplia variedad de
organizaciones.
2. Porque de esta manera pueden conectar sus instalaciones TCP/IP a la red global de
Internet.
La autoridad central, particion sus dominios en los siguientes subdominios:
COM
Organizaciones comerciales
EDU
Instituciones educativas
GOV
Instituciones gubernamentales
MIL
Grupos militares
NET
Centros mayores de soporte de red
ORG
Organizaciones
ARPA
Para ARPANET (obsoleto)
INT
Organizaciones internacionales
El nombre de nivel superior admite dos jerarquas de nombres diferentes:
1. El esquema geogrfico
2. El esquema organizacional
11

El geogrfico divide el universo de mquinas por pas.

Ejemplo:
El dominio para el estado de Virginia en EEUU seria: va.us
La desventaja de este esquema es que los nombres son largos y difciles de adivinar.
Como alternativa al esquema jerrquico geogrfico existe el organizacional. Si una
organizacin quiere registrarse bajo cierto dominio, se lo solicita a la autoridad central y sta
deber autorizarlo.
Ejemplo:
Una mquina en el departamento de ciencias de la Universidad de Purdue tiene el siguiente
dominio:
xinu.cs.purdue.edu
El nombre de la mquina (xinu) fue aprobado y registrado por el administrador de la red local
en el departamento de ciencias. El administrador de tal departamento haba obtenido previa
autorizacin para el dominio cs.purdue.edu de una autoridad de la red universitaria, quien a
su vez haba obtenido permiso para administrar el subdominio purdue.edu de la autoridad de
Internet. La autoridad de Internet conserva el control del dominio edu, de manera que nuevas
universidades puedan aadirse slo con su permiso.

22.9 Cosas por nombrar y sintaxis de los nombres

El esquema de nombres de dominio permite que los clientes distingan entre varios tipos de
entrada. Para esto, cada aspecto almacenado en el sistema es asignado a un tipo que
especifica si se trata de una mquina, buzn, usuario, etc.
Cuando una aplicacin solicita resolver el problema de un nombre, especifica qu tipo de
aspecto que est buscando.
Es importante entender lo siguiente:
Un nombre dado puede transformarse en ms de un aspecto en el sistema de
dominio. El cliente especifica el tipo de aspecto deseado cuando resuelve el
problema de un nombre, y el servidor devuelve objetos de ese tipo.
Adems de especificar el tipo de respuesta, el sistema de dominio permite al cliente
especificar la familia de protocolos que utilizar.

12

raz sin nombre

com

edu

gov

us

va
purdue

nsf
reston

cc

cs

ecn

Organizacional

cnri

Geogrfico

Figura 22

22.10 Asociacin de nombres de dominio en direcciones

El esquema de nombres de dominio incluye un sistema distribuido, confiable y de propsito
general para asociar nombres en direcciones.

Distribuido: Un conjunto de servidores opera en varias localidades de manera

conjunta.
Eficiente: La mayor parte de los nombres pueden ser asociados localmente, slo unos
pocos requieren trfico de red de redes.
Confiable: Una sola falla de una mquina previene al sistema para que opere
correctamente.

El mecanismo de dominio est conformado por sistemas independientes y cooperativos

llamados servidores de nombres. Un servidor de nombres es un programa servidor que ofrece
asociacin entre nombres y direcciones IP.
La forma ms fcil de entender cmo trabaja un servidor es verlo como un rbol que
corresponde a la jerarqua nombrada (Figura 22.3).

13

Servidor raz

Servidor .com

Servidor .edu

Servidor .gov

Servidor dec.com

Servidor purdue.edu

Servidor nsf.gov

Servidor .us Nivel Superior

Servidor va.us

Figura 22.3

La jerarqua del rbol se divide de la siguiente forma:

La raz del rbol es un servidor que reconoce el dominio de nivel superior y

sabe que servidor resuelve cada dominio.
En el siguiente nivel, un conjunto de servidores de nombre proporciona
respuestas para un dominio de nivel superior (Ej.: edu).Un servidor en este
nivel sabe que servidor puede resolver cada uno de los subdominios bajo su
dominio
En el tercer nivel del rbol, el servidor de nombres proporciona respuestas
para el subdominio (Ej.: purdue bajo edu).
El rbol conceptual contina con un servidor en cada nivel para el que se ha
definido un subdominio.

Las conexiones entre servidores no indican conexiones fsicas. Cada servidor puede estar en
una red distinta dentro de la red de redes.

22.11 Resolucin de nombres de dominio

CONTINUAR DESDE LA PGINA 395

22.12 Traduccin eficiente

22.13 Desempeo del cache: la clave de la eficiencia
22.14 Formato de los mensajes del servidor de dominios
22.15 Formato del nombre comprimido
22.16 Abreviatura de nombres de dominio
22.17 Asociaciones inversas
22.18 Bsquedas de apuntador
22.19 Tipos de objetos y contenido del registro de recursos
22.20 Obtencin de autoridad para un subdominio

14

15

23 Aplicaciones: acceso remoto

(TELNET y Rlogin)
23.2 Computacin remota interactiva
23.3 Protocolo TELNET
Permite establecer una conexin TCP con un servidor de acceso a otro. TELNET transfiere
las pulsaciones de teclado directamente desde el teclado del usuario a la computadora remota.
Tambin transporta la salida de la mquina remota de regreso al usuario. Este servicio se
llama transparent ya que el usuario ve como si su teclado y monitor estuvieran conectados
directamente a la mquina remota.
TELNET permite que el usuario especifique la mquina remota a travs del nombre de
dominio o de la direccin IP. Ofrece tres servicios bsicos:
1. Define una Terminal virtual de red que proporciona una interfaz estndar para los
sistemas remotos.
2. Incluye un mecanismo que permite negocias opciones entre cliente y servidor.
3. Maneja los extremos de la conexin de manera simtrica.
El cliente lee de
la terminal

Cliente
Telnet

El cliente manda al servidor

El servidor manda a una pseudo terminal

Servidor
Telnet

Disp.
de E/S
usuario
sistema
operativo

sistema
El servidor recibe del clienteoperativo

red de redes TCP/IP

Figura 23.1

Cuando un usuario invoca a TELNET, un programa de aplicacin se convierte en el cliente,

que establece la conexin TCP con el servidor. Una vez hecha la conexin, el cliente acepta
los pulsos de teclado y los enva al servidor. Concurrentemente, acepta los caracteres
enviados por el servidor y los muestra en la pantalla de usuario.
El servidor puede atender varias conexiones con distintos clientes. Lo que se muestra en la
figura 23.1 es un esclavo dentro del servidor que atiende una conexin con un cliente.
El termino pseudo terminal de la figura se refiere a que el servidor no enva los caracteres
directamente al terminal, sino que los manda al SO que acta simulando una terminal.

16

Que el servidor TELNET corra como una aplicacin cliente tiene como:

Ventaja: Es ms fcil controlarlo y modificarlo que si el servidor estuviera enclavado

en el SO.
Desventaja: Es menos eficiente porque los caracteres deben atravesar una capa mas
(el SO).

23.4 Adaptarse a la heterogeneidad

Para adaptarse a la heterogeneidad de los sistemas, TELNET define como deben mandarse
las secuencias de datos y comandos a travs de Internet. Dicha definicin se conoce como
network virtual terminal (NVT).
La idea es realizar una traduccin de las pulsaciones de teclado antes de enviarlas.

Disp.
de E/S
usuario

Cliente
Formato sistema cliente

conexin TCP

Formato NVT

Sistema del servidor

Servidor
Formato sistema servidor

Figura 23.2

La codificacin usada por NVT es USASCII, que incluye 95 caracteres imprimibles y 33

cdigos de control. Cada cdigo de control de USASCII tiene una interpretacin determinada
dentro de NVT (ver figura 23.3 en el libro) y los caracteres imprimibles tienen el mismo
significado que el conjunto de caracteres estndar de USACII.
Ejemplo:
Si el usuario presiona ENTER, el cliente deber traducir el cdigo que el sistema cliente usa
para el ENTER a CR-LF del sistema NVT y eso es lo que viaja a travs de la conexin TCP
hasta el servidor que luego traducir CR-LF al cdigo que use el sistema del servidor.

23.5 Transferencia de comandos que controlan extremo remoto

NVT adapta las funciones de control creando funciones de control conceptuales. Algunas de
esas funciones son:
IP
(Interrupt Process)
Interrupcin del proceso
AO
(Abort Output)
Salida abortada
AYT
(Are You There)
Estas ah. Prueba si el servidor responde
EC
(Erase Character)
Borra carcter.
EL
(Erase Line)
Borra lnea
SYNCH
(Syncronize)
Sincroniza. Despeja la trayectoria de datos
hasta que el punto de datos TCP es urgente, pero interpreta comandos
BRK
(Break)
Teclas de pausa o seal de atencin
El hecho de que NVT separe la definicin de comandos de control
normales tiene dos ventajas:

*1

de los caracteres ASCII

1. Permite mayor flexibilidad, porque de esta forma se pueden transmitir todas

las secuencias de caracteres ASCII posibles entre el cliente y el servidor *2
2. Permite que el cliente especifique las seales de manera no ambigua.
TELNET codifica los comandos de control a travs de TCP usando la secuencia de escape. O
sea que enva un byte IAC (Internet as Command) que indica que a continuacin sigue un
comando de control (Para ver los comandos de control, ver la figura 23.5 en el libro, pagina
17

415). Cuando se va a enviar un IAC y en los datos existe un carcter IAC, este se enva dos
veces.

23.6 Forzar al servidor a leer una funcin de control

En ciertos casos, puede pasar que los buffers del servidor estn llenos, entonces el servidor
anuncie un tamao de ventana cero lo que evita la transferencia de datos a travs de la
conexin TCP. Si en ese momento el usuario enva un IAC IP para finalizar la aplicacin, el
servidor no leer la secuencia porque TCP ha dejado de enviar datos a la mquina del
servidor. Para evitar esto, TELNET utiliza una seal fuera de banda. Esto se implementa
con el mecanismo de dato urgente. Cuando se va a transmitir un comando de control,
TELNET tambin enva un comando SYNCH, luego anexa un byte especial llamado marca
de datos y hace que TCP enve los datos con el bit de URGEN DATA.
Los segmentos que llevan los datos urgentes evitan el control de flujo y as logran llegar al
servidor.

23.7 Opciones de TELNET

En TELNET las opciones son negociables, con lo que se logra reconfigurar una conexin
entre el cliente y el servidor. El rango de opciones es bastante amplio. Por ejemplo, una de las
opciones permite que TELNET opere en half-duplex (modo de operacin normal) o fullduplex (Para ver ms opciones ver la figura 23.6 en el libro, pagina 417).

23.8 Negociacin de opciones de TELNET

Telnet utiliza un mecanismo de negociacin de opcin simtrica para permitir a los
clientes y a los servidores reconfigurar los parmetros que controlan su
interaccin. Como el software TELNET comprende un protocolo NVT bsico, los
clientes y los servidores pueden interoperar aun cuando uno comprenda las
opciones y el otro no.

23.9 Rlogin (BSD de UNIX)

*1: Ntese la diferencia entre caracteres de control y comando de control. El primero es un cdigo ASCII que
sirve por ejemplo para mover el cursor, indicar una nueva lnea, etc. Los caracteres de control llegan a la
aplicacin cliente. En cambio los comandos, no llegan al cliente, ya que indican una terminacin abrupta, o una
consulta al servidor, etc.
*2: Recordar que los comandos no llegan a la aplicacin cliente. Por ejemplo, cuando se presiona CTRL+C para
la terminacin de un programa, este nunca se entera de que el usuario presion esa combinacin de teclas, ya
que el SO lo mata antes.

18

24 Aplicaciones: transferencia y acceso de archivos

(FTP, TFTP, NFS)
24.2 Acceso y transferencia de archivos
Algunos sistemas son pensados como unidades centrales de almacenamiento que
proporcionan almacenamiento secundario a un conjunto de mquinas de bajo costo que no
poseen disco. Otros diseos se valen del almacenamiento remoto para archivar datos y en
otros casos la motivacin principal es la comparticin de datos entre varios usuarios.

24.3 Acceso compartido en lnea

Compartir archivos se presenta en dos formas:
1. Acceso en lnea
2. Copiado de archivo completo
El primero significa que permite a varios programas acceder de manera concurrente a un solo
archivo y los cambios estarn disponibles para todos los que acceden, mientras que el
copiado significa que cada vez que un programa quiera acceder a un archivo, este obtendr
una copia local. El copiado se usa generalmente para datos de solo lectura, pero en caso de
que se hagan modificaciones, el programa hace los cambios locales y luego transfiere de
regreso el archivo modificado a la localidad original.
Los archivos remotos estn integrados con los archivos locales, es decir, el usuario no
necesita acceder a los remotos a travs de aplicaciones cliente particulares, sino que el acceso
a ellos es idntico al acceso a los locales, por lo tanto se dice que se proporciona acceso
transparente, lo que brinda como ventaja que el acceso a archivos remotos ocurre sin
cambios visibles en los programas de aplicacin.
Esta integracin entre mquinas puede verse complicada por la diversidad de arquitecturas y
SO que estas puedan utilizar.

24.4 Compartir mediante transferencia de archivos

Acceder a datos remotos a travs de una transferencia requiere dos pasos:
1. Obtener la copia local
2. Trabajar en la copia
La mayor parte de los mecanismos de transferencia no estn integrados, por eso para que el
usuario pueda transferir debe acceder a aplicaciones cliente de propsito especial a las que le
deber especificar la mquina de la que se obtendrn los archivos adems de cuenta y clave
(de ser necesario).

24.6 Caractersticas de FTP

FTP (File Ttransfer Protocol) es un protocolo complejo porque lidia con las diferentes
arquitecturas de mquinas y adems brinda ms facilidades que la simple transferencia.

Acceso interactivo: Si bien est orientado para usarse mediante programas, posee
una interfaz que permite a los usuarios interactuar con los servidores remotos.
Especificacin de formato: El FTP permite especificar al usuario el tipo y formato
de los datos almacenados.
Control de autenticacin: Requiere que los usuarios se autoricen a si mismos con el
envo de nombre de conexin y una clave de acceso al servidor.

24.7 Modelo de proceso FTP

Un proceso servidor maestro espera las conexiones y crea un proceso esclavo para manejar
cada conexin, pero a diferencia de casi todos los servidores, el proceso esclavo no ejecuta
19

todos los cmputos necesarios, sino que crea un proceso (o varios) adicional que se encarga
de manejar la transferencia de manera separada.
Por la conexin de control se transmiten comandos que le dicen al servidor que archivo
transferir, mientras que los datos viajan por la conexin de transferencia de datos. Ambas
conexiones utilizan TCP como transporte.
Las conexiones y procesos de transferencia de datos pueden crearse de manera
dinmica cuando se necesitan, pero la conexin de control contina a travs de una
sesin. Una vez que la conexin de control desaparece, la sesin se termina y el
software en ambos extremos termina todos los procesos de transferencia de datos.

sistema cliente

sistema servidor

transf. de datosproceso de control

conexin de control de cliente
proceso de controltransf. de datos

sistema
operativo

conexin de control de servidor

sistema
operativo

red de redes TCP/IP

Figura 24.1

24.8 Asignacin de nmeros de puerto

CONTINUAR DESDE LA PGINA 428

24.10 Ejemplo de una sesin con FTP annimo

El acceso al FTP annimo significa que un cliente no necesita una cuenta o clave para
acceder al servidor de recursos sino que accede con un nombre de conexin annimo y una
clave de invitado. El servidor restringe el acceso a los archivos pblicos que figuran en el
servidor.
Los mensajes de control y error entre el cliente y servidor FTP comienzan con un
nmero de tres dgitos seguido de texto. El software interpreta el numero; el texto
est dirigido a los usuarios.

24.11 TFTP
TFTP (Trivial File Transfer Protocol) es un segundo protocolo del grupo de protocolos
TCP/IP que se utiliza para la transferencia de archivos. Es una versin simplificada de FTP
para aquellas mquinas que no necesitan o no pueden soportar la complejidad del FTP, ya
que este requiere que se manejen varias conexiones TCP/IP simultneas. TFTP restringe las
operaciones a transferencia de archivos sencilla y no proporciona autenticacin.
20

SE PUEDE AGREGAR INFORMACION (PAGINA 432)

24.12 NFS
NFS (Network File System) proporciona un acceso de archivos compartidos en lnea que es
transparente e integrado.

24.13 Implantacin NFS

NFS se encuentra embebido en el SO. El mecanismo de acceso a archivos recibe las
peticiones y las transmite de manera automtica al SW de sistema de archivos local o del
cliente NFS dependiendo de si el archivo solicitado esta en el disco local o en una mquina
remota.

aplicacin

Mecanismo de acceso a archivos

Local File System

Disco local

Cliente
NFS

Conexin de red de redes hacia el servidor NFS

Figura 24.3

24.14 Llamada de procedimiento remoto (RPC)

En lugar de definir el protocolo NFS de cero, los diseadores prefirieron construir tres piezas
independientes.
El protocolo NFS, es un mecanismo general de llamada de procedimiento remoto o RPC
(Remote Procedure Call) y una representacin de datos externa o XDR (External Data
Representation).
Desde el punto vista del programador, NFS no proporciona por si mismo nuevos
procedimientos que un programa pueda llamar, pero una vez que un administrador configura
el NFS los programas pueden acceder a los archivos remotos de la misma forma que acceden
a los archivos locales. RPC y XDR proporcionan mecanismos que los programadores pueden
usar para crear programas distribuidos.
Ejemplo RPC:
Un programador puede dividir un programa de un lado como cliente y de otro como servidor
y usar RPC como principal mecanismo de comunicacin. En el lado cliente, el programador
21

designa como remotos algunos procedimientos, forzando as al compilador a incorporar el

cdigo RPC en dichos procedimientos. En el lado del servidor, el programador implanta los
procedimientos deseados y utiliza otras caractersticas de RPC para declararlos como parte de
un servidor. Cuando el cliente llama a los procedimientos remotos, el RPC recolecta
automticamente los valores para los argumentos, forma el mensaje y lo enva al servidor,
espera una respuesta, y cuando llega alacena los datos devueltos en los argumentos
designados. Entonces, gracias a RPC, la comunicacin ocurre de manera automtica,
haciendo posible que el programador se abstraiga de los detalles de la misma.
Ejemplo XDR:
Brinda a los programadores una manera de transmitir datos entre mquinas heterogneas de
manera transparente. El caso puntual de aplicacin puede verse en la escritura de enteros de
32 bits. Algunos sistemas utilizan Big Endian y otros Little Endian, por lo tanto si no se
hicieran las traducciones necesarias, el valor del entero pondra cambiar de un sistema a otro.
XDR resuelve este problema definiendo una presentacin independiente en cada mquina. En
un extremo de la comunicacin, un programa invoca procedimientos XDR para hacer la
conversin de la representacin del hardware local a la representacin independiente de
mquina. Una vez que los datos son transmitidos, se realizar el mismo proceso pero
invertido en el otro extremo.

24.15 RPC Port Mapper

El Port Mapper mapea programas RPC con nmeros de puertos. Este programa realiza un
binding dinmico de posibles programas remotos. Esto es deseable ya que el rango de los
nmeros de puerto reservados es muy pequeo en relacin al nmero de programas remotos,
que potencialmente es muy grande.
Tambin ayuda en la comunicacin RPC. Cuando un RPC en el servidor inicia, el sistema le
puede asignar un puerto arbitrario y ese puerto puede no ser conocido por el cliente, por lo
tanto el cliente no sabr a qu puerto enviar los paquetes para utilizar el RPC. El port mapper
tiene dos funciones para solucionar esto.
1. La primera es que el port mapper siempre escucha en el mismo puerto, por eso los
clientes saben a priori a que direccin enviar los paquetes.
2. La segunda es que cuando un RPC inicie, le informar al port mapper que puerto le
fue asignado y que nmeros de programa est preparado para atender, as cuando un
cliente invoque al RPC el port mapper le indicar al cliente a donde enviar los datos.
Por tal motivo el port mapper debe ser iniciado antes que cualquier RPC.
El Port Mapper soporta dos protocolos UDP y TCP, y es accedido desde el puerto 111.
Los procedimientos del Port Mapper son los siguientes:

PMAPPROC_NULL: Este procedimiento no realiza ningn trabajo. Por convenio,

el procedimiento nulo de cualquier protocolo no requiere parmetros y no retorna
ningn resultado.
PMAPPROC_SET: Cuando un programa esta disponible en una mquina, se registra
el mismo con el programa Port Mapper en la misma mquina. El programa pasa su
nmero de programa, su nmero de versin, su nmero de protocolo de transporte y
el puerto donde espera servicio. El procedimiento retorna una variable booleana
puesta a TRUE si el procedimiento ha establecido correctamente el mapeo, y FALSE
en cualquier otro caso. El procedimiento rechaza el establecimiento del mapeo si ya
existe una tupla (programa, versin, protocolo).

22

PMAPPROC_UNSET: Cuando un programa ya no esta disponible, debe eliminarse

l mismo con el Port Mapper en la misma mquina. Los parmetros y resultado tienen
el mismo significado que en el procedimiento anterior. El nmero de protocolo y de
puerto son ignorados en este procedimiento.
PMAPPROC_GETPORT: Dado un nmero de programa, un nmero de versin y
un nmero de protocolo de transporte, este procedimiento retorna el nmero de puerto
en donde el programa est esperando solicitudes. Un nmero de puerto igual a cero,
quiere decir que el programa no ha sido registrado. El argumento puerto es ignorado.
PMAPPROC_DUMP: Este procedimiento enumera todas las entradas en la base de
datos del port mapper. El procedimiento no toma parmetros y retorna una lista de
programa, versin, protocolo y valores de puerto.
PMAPPROC_CALLIT: Este procedimiento permite a un cliente llamar a otro
procedimiento remoto en la misma mquina, sin conocer el nmero de puerto del
procedimiento remoto. Est destinado para soportar broadcast a programas remotos
arbitrariamente va los puertos conocidos del port mapper.
Este procedimiento solo enva respuesta si el procedimiento ha sido correctamente
ejecutado y no responde en otros casos.
El Port Mapper comunica con el programa remoto utilizando solamente el protocolo
UDP.
Este procedimiento retorna el nmero de puerto del programa remoto, y la respuesta
es la respuesta del procedimiento remoto.

24.16 Servicios, Puertos y Procesos

Un proceso de servicio RPC se asocia a un programa constituido por un conjunto de
procedimientos, mediante un nmero de identificacin. Cuando hay una llamada a un
procedimiento existir un proceso encargado de la ejecucin del servicio solicitado. Esto
implica que se tiene acceso al cdigo de los diferentes procesos de servicio. El proceso de
servicio comunica con el modulo solicitado a travs de un socket del dominio INTERNET, es
decir mediante un protocolo de transporte: UDP o TCP. El socket en cuestin se asocia a un
nmero de puerto. Puede ocurrir que se genere el proceso de servicio para que est
permanentemente a la escucha en el puerto asociado, o que el puerto asociado forme parte de
un conjunto de puertos sobre los que escucha un proceso particular. Este ltimo proceso es el
que crear el proceso de servicio en el momento adecuado.

24.17 El proceso Portmap

Este es un proceso que responde a un servicio RPC reservado (numero de programa 100000
y puerto 111). Su misin es la de asociar un nmero de puerto a cada nmero de servicio
RPC dado. Para establecer una transmisin RPC este proceso debe estar activo. Por esto,
cada nuevo servicio disponible debe ser notificado al proceso Portmap del sistema (proceso
llamado: mecanismo de grabacin de servicio).

23

25 Aplicaciones: Correo electrnico

25.2 Correo electrnico
A diferencia de otros protocolos, el correo electrnico puede manejar las entregas con
retraso. Esto es, enviar el correo a pesar de que las conexiones hayan fallado o que la
mquina remota no est disponible. Para lograrlo, se utiliza una tcnica conocida como
spooling. En el envo, se coloca una copia del mensaje en un rea de almacenamiento
privado, y el sistema inicia una actividad subordinada que realiza el envo hacia la mquina
remota mientras el emisor puede dedicarse a otras tareas.

envo de correo del usuario

Interfaz de usuario

rea spool
de salida
de correo

cliente (transferencia subordinada)

conexin TCP

lectura de correo del usuario

buzones
para correo
entrante

para salida de correo

servidor
conexin TCP
(para aceptar correo)
para correo entrante

Figura 25.1

25.3 Nombres y alias de los buzones de correo

Tres ideas importantes:
1. Los usuarios especifican recipientes, proporcionando pares de cadenas que
identifican el nombre de la mquina y la direccin de buzn.
2. Los nombres utilizados en estas especificaciones son independientes de otros
nombres asignados a las mquinas. Usualmente la direccin de un buzn es la misma
que la del usuario frente al sistema, y el nombre de la mquina el mismo que el del
dominio de la mquina aunque esto no tiene que ser as necesariamente.
3. La tercera realmente no se entiende, verla del libro (pgina 441).

25.4 Expansin de alias y direccionamiento de correspondencia

Los alias incrementan la funcionalidad del correo electrnico. Permiten a una persona tener
varios identificadores de correo como tambin generar un identificador asociado a varias
direcciones (listas de correo electrnico).
Normalmente, luego de que el usuario compone el mensaje y nombra un recipiente, el
programa de interfaz de correo consulta los alias locales para reemplazar el recipiente con la
versin transformada antes de pasar el mensaje al sistema de entrega.

25.5 relacin entre el enlace de redes y el correo electrnico

Existen sistemas que pueden enviar e-mails sin estar conectados a Internet.
24

Cul es la diferencia entre estos y los que se describen ac?

1. La primera es que una red de redes TCP/IP hace posible el servicio de entrega
universal.
2. El sistema de correo TCP/IP es inherentemente ms confiable.
La primer razn es fcil de validar, ya que TCP/IP proporciona conexin a todas las
mquinas en la red de redes, y en esencia todas las mquinas estn conectadas a una sola red.
La segunda se debe a que dado que el sistema emisor puede determinar siempre el estado
exacto de un mensaje, ste puede guardar una copia hasta tener la certeza de que el mensaje
fue correctamente enviado al servidor.
Los sistemas de correo que utilizan la entrega EAE pueden garantizar que cada
mensaje de correo se mantenga en la mquina del emisor hasta ser copiado con
xito en la mquina del receptor.
Una alternativa a la entrega EAE es el uso de mail gateways. Es este caso los envos se
realizan a una mquina intermedia que se encarga de completar el envo.
Las desventajas de las compuertas de mensajes son:

Una disminucin de la confiabilidad ya que una vez que se envi una copia al
intermediario, se borra la copia local y mientras tanto ni el emisor ni el receptor
tienen una copia del mensaje.
Introduccin de retardos.

Las ventajas:

Interoperabilidad. Permite enviar mensajes entre redes que soportan diferentes

tecnologas.

25.6 Estndares TCP/IP para el servicio de correo electrnico

TCP/IP persigue la interoperabilidad entre un amplio rango de sistemas. Para extenderla en el
sistema de correo, divide sus entandares en dos grupos:
1. Uno especifica el formato de los mensajes.
2. El otro especifica los detalles de intercambio de correo entre dos computadoras.
Un mensaje de correo est compuesto por un encabezado y por un cuerpo. El estndar TCP /
IP para los mensajes de correo, especifica el formato del encabezado as como su
interpretacin. Por ejemplo, debe contener una lnea que especifique el destino y otra que
especifique el remitente (To: y From:). Algunos campos del encabezado son opcionales,
como por ejemplo el campo de direccin de rplica (Cc:).

25.7 Direcciones de correo electrnico

Normalmente las direcciones de correo poseen una forma sencilla de recordar:
parte-local@nombre-dominio
Donde el nombre de dominio es el nombre de dominio de un destino de correo (tcnicamente
especifica un distribuidor de correo, no un nombre de mquina) al que el correo debe ser
entregado y parte local es la direccin de un buzn en la mquina.
Ejemplo:
25

comer@purdue.edu
Sin embargo, las compuertas de correo pueden volver complejas a las direcciones.
Cualquiera que est fuera de Internet, deber direccionar a la compuerta de correo ms
cercana, o tener un SW que lo haga automticamente.
parte-local % nombre-dominio @ compuerta
Ejemplo:
comer % purdue.edu @ relay.cs.net

25.8 Pseudo direcciones de dominio

Es una forma que ayuda a resolver el problema de los diversos sistemas de correo, cada uno
con su propio formato de direccin, logrando que para el usuario todas las direcciones de
correo tengan la misma forma. Esto se logra utilizando direcciones especiales que sern
luego traducidas por el SW para el envo de correo.

25.9 Protocolo de transferencia de correo simple (SMTP)

SMTP (Simple Mail Transfer Protocol) es el protocolo de transferencia estndar.
SMTP se enfoca en:

Como el sistema de entrega de correo subyacente transfiere los mensajes a travs del
enlace de una mquina a otra.

SMTP no especifica:

De que manera el sistema de correo acepta los mensajes de un usuario.

Como representa al usuario la interfaz de usuario de correo entrante.
Como se almacena el correo
Con que frecuencia el sistema de correo intenta enviar mensajes.

El establecimiento de la conexin entre cliente y servidor sigue el siguiente esquema:

1. El cliente establece una conexin de flujo confiable (TCP) y espera que el servidor
enve el mensaje 220 READY FOR MAIL.
2. Al recibir el mensaje, el cliente enva el mensaje HELO (abreviatura de HELLO).
3. El servidor responde identificndose.
4. Una vez que se estableci la comunicacin el emisor puede transmitir uno o ms
mensajes de correo.
5. El emisor puede terminar la conexin o solicitar al receptor que se intercambien los
roles de emisor y receptor para que los mensajes puedan fluir en direccin opuesta
(mensaje TURN).
6. El receptor debe enviar un acuse de recibo por cada correo recibido.
7. El receptor tambin puede abortar la transferencia.
Una transaccin de correo sigue los siguientes pasos:
1. Se comienza con el envo del comando MAIL, que proporciona la identificacin del
emisor as como un campo FROM que contiene la direccin a donde se debern
reportar los errores.
2. Un recipiente prepara su estructura de datos para recibir un nuevo correo y responde
al comando MAIL enviando un 250 OK.
26

3. Cuando al emisor le llega el 250 OK, emite una serie de comandos RCPT que
identifican a los recipientes del mensaje de correo. Los receptores deben enviar un
acuse de recibo por cada comando RCPT enviando un 250 OK o 550 No Such User
Here.
4. Despus de que todos los comandos RCPT han sido reconocidos, el emisor emite un
comando DATA que indica al receptor que el emisor esta listo para enviar un correo
completo.
5. El receptor responde 354 Start mail input y especifica la secuencia de caracteres para
terminar el mensaje de correo.
La conexin se cierra en dos pasos. Primero el emisor enva una orden QUIT y espera una
respuesta. Luego sigue cerrando la conexin TCP. El receptor har lo propio luego de enviar
su respuesta a la orden QUIT.
El siguiente ejemplo tomado de la RFC 821 muestra el proceso:

25.10 La extensin MIME para datos no ASCII

MIME (Multipurpose Internet Mail Extension) fue creado para la transmisin de datos no
ASCII a travs de e-mail. La MIME no cambia ni reemplaza a SMTP, sino que lo extiende.
De hecho permite que datos arbitrarios sigan codificndose en ASCII y luego se enven a
travs de mensajes de mail estndar.
La informacin MIME reside dentro del encabezado 822 y posee cinco campos:
1.
2.
3.
4.
5.

versin MIME
Tipo de contenido
Codificacin de transferencia de contenido
Identificador del contenido
Descripcin del contenido

Los posibles tipos de contenido son:

1.
2.
3.
4.

Texto
Multiparte
Mensaje
Audio
27

5. Imagen
6. Video
7. Aplicacin

25.11 Mensajes MIME multipart

El tipo de contenido multipart permite cuatro subtipos:
1. Mixed: permite que un slo mensaje contenga submensajes independientes en donde
cada uno tiene un tipo independiente y una codificacin diferente. Un mensaje podr
contener audio, imgenes y otros formatos en simultneo.
2. Alternative: permite que un slo mensaje sea representado de diferentes formas. Esto
es til cuando se envan mensajes a varios recipientes que no utilizan el mismo HW /
SW de sistema.
3. Parallel: Permite que un mensaje tenga subpartes que tengan que ser vistas todas
juntas. Por ejemplo, subpartes de imagen y video que deben presentarse de manera
simultnea)
4. Digest: Permite que un solo mensaje contenga un conjunto de otros mensajes. Por
ejemplo, la coleccin mensajes de una discusin.

25.12 El comando TURN

Este comando (descrito en la RFC 821), conlleva importantes problemas de seguridad,
debido a que en ausencia de una fuerte autenticacin del host que pide que el cliente y el
servidor intercambien roles, puede ser fcilmente utilizado para desviar correos de su destino
correcto, por tal motivo su uso fue deprecado. Los sistemas SMTP no deberan usarlo a
menos que puedan autentificar al cliente.

28

28 Seguridad de Internet y diseo del muro de seguridad

28.1 Introduccin
La seguridad se apoya en tres acciones principales:
1. Prevencin
2. Deteccin
3. Reaccin
Prevenir los ataques, detectarlos en caso de que ocurran y reaccionar ante tales detecciones.

28.2 Recursos de proteccin

Seguridad significa integridad de los datos, confianza en que no existan accesos no
autorizados, que los recursos estn libres de intromisiones y que no hay interrupciones de
servicios.

Integridad
Autenticidad
Privacidad
Disponibilidad

La seguridad est ligada no solo a los recursos fsicos sino tambin a los recursos abstractos,
siendo esta ultima ms difcil de implementar. La integridad de datos as como la
disponibilidad de datos son cruciales, y como la informacin puede ser accedida a travs de
una red, la proteccin debe prevenir lecturas no autorizadas.

28.3 Necesidad de una poltica de informacin

Antes de que se implante un proyecto de seguridad, la organizacin debe asumir riesgos y
desarrollar una poltica clara de accesos de informacin y proteccin y darla a conocer a
todos sus empleados. Esto es crucial dado que:
Las personas son por lo general el punto ms susceptible de cualquier esquema
de seguridad. Un trabajador malicioso, descuidado o ignorante de las polticas
de informacin puede comprometer la seguridad.
Un empleado debe ser capaz de responder preguntas bsicas como:

Qu tan importante es la informacin para la organizacin?

Qu significan los derechos de autor?
Qu tanto de la informacin a la que tiene acceso puede discutir con otros
empleados?
Qu informacin puede importar a la compaa?
Qu son los derechos de propiedad intelectual?

Las polticas de informacin deben abarcar tanto la informacin entrante como la

saliente.
Las polticas de informacin pueden entrar en conflicto. Por ejemplo, si se consideran tres
organizaciones A, B y C, donde A permite que la informacin fluya hacia B pero no hacia C,
si la poltica de B permite fluir informacin hacia C eso entrara en conflicto con las polticas
de A.

28.4 Comunicacin, cooperacin y desconfianza mutua

29

Se dice que cuando tres organizaciones intercambian informacin, la seguridad de la poltica

de seguridad es el cierre transitivo de las polticas de seguridad individuales. Como
resultado:
Una organizacin no puede conocer el efecto de comunicarse e interactuar con
otras a menos que las dos organizaciones acuerden un nivel de confianza
recproca.

28.5 Mecanismos para la seguridad de Internet

Los problemas de seguridad y los mecanismos de software que ayudan a prevenirlos pueden
clasificarse en tres conjuntos:
1. El primero se enfoca en la autorizacin, autenticacin e integridad.
2. El segundo en el problema de la privacidad.
3. El tercero en la disponibilidad mediante el control de acceso.

28.5.1 Mecanismos de autenticacin

Resuelven el problema de verificar la identificacin. Cuando un cliente hace un primer
contacto con un servidor, este debe verificar que el cliente este autorizado antes de prestar el
servicio. El servidor puede utilizar diferentes tcnicas para autenticar. Una de esas tcnicas es
identificar al cliente segn su direccin IP, aunque puede ser violada con facilidad si es que
un router que rutea paquetes al servidor es controlado por un impostor. El impostor puede
actuar como servidor para un cliente como de cliente para un servidor. La solucin a este
problema radica en proporcionar un servicio confiable. Una forma de lograr esto es a travs
del cifrado de clave pblica. Para usar un sistema de clave pblica cada participante debe ser
asignado a dos claves que son utilizadas para codificar y decodificar mensajes. Cada clave es
un entero largo.

Un participante publica una clave, llamada clave pblica, en una base de datos
pblica y conserva la otra en secreto.
Un mensaje se codifica mediante una clave que se puede decodificar usando la otra.

Por ejemplo, un emisor codifica un mensaje con la clave pblica del receptor. Ese mensaje
puede solamente ser decodificada con la clave privada del receptor que slo el receptor
conoce. Un cliente y un servidor que utilicen cifrado de clave pblica pueden estar
razonablemente seguros de que su interlocutor es autntico, an si sus datagramas pasan a
travs de una red poco segura.

28.5.2 Mecanismos de privacidad

Para dar privacidad con el mecanismo de cifrado de clave pblica se procede de la siguiente
forma:
Supongamos dos participantes Ay B. Ambos tienen una clave pblica y otra privada. Si A
tiene que enviar un mensaje a B y quiere que no sea ledo por nadie ms que B, lo que hace
es encriptar ese mensaje con la clave pblica de B. Ese mensaje podr ser desencriptado
nicamente con la clave privada de B, clave que es nicamente conocida por B. As nos
aseguramos que slo B lea el mensaje (privacidad).
En caso de que se quiera otorgar autenticidad e integridad se procede de la siguiente forma:

30

Si A quiere enviar a B un mensaje y quiere que B sepa que slo l (A) le pudo haber enviado
ese mensaje, lo que hace A es encriptar el mensaje con su propia clave privada. Ese mensaje
podr ser desencriptado con la clave pblica de A. Con esto no se puede asegurar que slo B
lea el mensaje (no aseguro privacidad), pero s se asegura la autenticidad ya que B sabe que
solamente A puede haberle enviado el mensaje, porque nadie ms puede encriptar con la
clave privada de A.
En caso de querer otorgar autenticidad y privacidad en simultneo se procede a un doble
encriptado:
Primero A encripta con su clave privada y luego encripta con la clave pblica de B.

28.6 Firewalls y acceso a Internet

Los mecanismos de control de acceso a la red de redes manejan el problema del filtrado
hacia las redes de las comunicaciones no previstas. A diferencia de los mecanismos de
autenticacin y privacidad que pueden ser implementados a nivel de capa de aplicacin, el
control de acceso a la red por lo general requiere cambios en los componentes bsicos de la
infraestructura de la red. Una tcnica para implementar esto es la de la creacin de un
firewall. Un firewall aparece como entrada a la red de redes que ser protegida, y divide a la
red de redes en dos regiones que se conocen informalmente como el interior y el exterior.
Firewall de la organizacin

Red de la organizacin

Resto de Internet

exterior

interior
Figura 28.1

28.7 Conexiones mltiples y vnculos ms dbiles

En ciertos casos la imagen conceptual presentada por la figura 28.1 puede complicarse dado
que una organizacin puede poseer una red interna que tenga varias conexiones externas. En
tal caso, se deber formar un permetro de seguridad instalando un muro de seguridad en
cada conexin externa, los cuales debern estar coordinados para que posean restricciones de
acceso idnticas.
Una organizacin que tiene mltiples conexiones externas debe instalar un muro de
seguridad en cada conexin externa y coordinar todos los muros de seguridad. Las
fallas para restringir en forma idntica el acceso en todos los muros de seguridad
pueden hacer que la organizacin sea vulnerable.

28.8 Implantacin de firewall y hardware de alta velocidad

En teora, un firewall bloquea todas las comunicaciones no autorizadas entre mquinas
internas y externas a la organizacin. En la prctica esto depende de las polticas de la
organizacin, la carga de trfico y la capacidad de conexin.
La implantacin de un firewall requiere de una alta capacidad de procesamiento ya que se
deben analizar todos los datagramas que viajan a travs de l (dentro-fuera o fuera-dentro).
Muchos routers poseen un mecanismo de filtrado de alta velocidad que puede usarse para
realizar muchas de las funciones necesarias, y pueden configurarse para que bloqueen
datagramas especficos.
31

28.9 Filtros de nivel de paquetes

El trmino filtrado de paquetes se debe a que el mecanismo de filtrado no conserva un
registro de las interacciones o una historia de los datagramas previos, por el contrario, el
filtro considera a cada datagrama de forma separada.
Como TCP / IP no dicta un estndar de filtrado, cada fabricante de routers puede seleccionar
las caractersticas que desee darle a su filtro. Algunos routers permiten configurar opciones
de filtrado diferentes para cada interfaz. Los parmetros de filtrado pueden ser direcciones IP
de origen o destino, numero de puerto, protocolo fuente, etc.

28.10 Especificacin de seguridad y de filtro de paquetes

El uso de listas de filtrado (se pueden filtrar puertos bien conocidos, direcciones IP,
protocolos, etc.) en un firewall puede tener ciertos inconvenientes:

El nmero de puertos bien conocidos es extenso y un administrador podra necesitar

actualizar la lista continuamente debido a que un simple error puede volver
vulnerable al muro.
Gran parte del trfico no viaja desde o hacia puertos bien conocidos. Adems el uso
de Port Mapper asigna puertos dinmicamente para las aplicaciones que as lo
requieran.
Los filtros pueden ser vulnerados por el uso de tneles. Un datagrama prohibido
puede viajar encapsulado hacia un puerto habilitado.

Para sortear estos problemas con las listas de filtrado, lo que se hace es justamente lo inverso,
en vez de listar los datagramas que deben filtrarse, un firewall se configura para bloquear
todos los datagramas, excepto aquellos destinados a redes especficas, anfitriones y puertos
de protocolo para los que se ha aprobado la comunicacin.

28.11 Consecuencia del acceso restringido para clientes

Si el firewall de una organizacin restringe los datagramas entrantes excepto para puertos que
corresponden a servicios puestos a disposicin del exterior, una aplicacin del interior no
podr volverse cliente de un servicio del exterior. Esto es porque:

Cuando un cliente trata de comunicarse con un servidor de afuera, genera uno o ms

datagramas y los enva.
Cada datagrama que sale, tiene el puerto de protocolo del cliente como puerto de
origen, y el puerto bien conocido del servidor como puerto de destino.
El firewall no bloquea los datagramas salientes.
Cuando se genera una respuesta, el puerto del cliente se vuelve el puerto de destino y
el del servidor el puerto fuente.
Cuando el datagrama llegue al firewall, ser bloqueado ya que el puerto de destino
no est aprobado.

28.12 Acceso a servicios a travs de un firewall

Dado la problemtica del punto anterior, los usuarios necesitan un mecanismo seguro que
proporcione acceso a servicios del exterior.
En lugar de tratar de hacer que todas la maquinas de una organizacin sean seguras, lo que se
hace es asociar una computadora segura con cada firewall, y se la conoce como anfitrin
baluarte.

32

Anfitrin baluarte

Red de redes interior

Red de redes exterior

Barrera exterior

Barrera de entrada

Derivacin habilitada manualmente

Figura 28.3

La barrera exterior bloquea todo el trfico entrante excepto:

1. Datagramas destinados a servicios en el anfitrin baluarte que la organizacin elige
mantener disponibles al exterior.
2. Datagramas destinados a clientes en el anfitrin baluarte.
La barrera de entrada bloquea el trfico entrante excepto datagramas que vienen del anfitrin
baluarte.

28.13 Detalles de la arquitectura de un firewall

Las barreras mencionadas en el tem anterior, son implementadas con routers que poseen
filtros de paquetes. Las redes interconectan los routers y el anfitrin baluarte.
An cuando un anfitrin baluarte es esencial para la comunicacin a travs de
un firewall, la seguridad de dicho firewall depende de la seguridad en el anfitrin
baluarte. Un intruso que abra una grieta en la seguridad en el SO del baluarte
puede lograr el acceso del anfitrin dentro del firewall.

28.15 Implantacin alternativa de un firewall

28.16 Monitoreo y establecimiento de conexin

33

29 El futuro de TCP/IP
(IPng, IPV6)
29.2 Por qu cambiar TCP/IP e Internet?
29.2.1 Nuevas tecnologas de comunicacin y computacin
Continuamente estn saliendo nuevas tecnologas que los profesionales prueban en diferentes
mbitos y aplicaciones y que pueden producir mejoras significativas y fomentar cambios en
las implementaciones ya existentes.

29.2.2 Nuevas aplicaciones

Las nuevas aplicaciones crean una demanda continua de infraestructura y servicios que los
protocolos actuales no pueden proporcionar.

29.2.3 Incrementos en el tamao y en la carga

Los ltimos aos Internet ha experimentado un crecimiento exponencial tanto en tamao
como en trfico y todo apunta a que esta tendencia se siga manteniendo.

29.2.4 Nuevas polticas

A medida de que Internet se expande hacia nuevos pases, cambia de forma adquiriendo
nuevas autoridades administrativas. Los cambios en las autoridades provocan cambios en las
polticas administrativas. La evolucin contina conforme se conectan ms columnas
vertebrales de redes nacionales, produciendo un incremento complejo de las polticas que
regulan la interaccin.

29.3 Motivos para el cambio del IPV4

Algunas de las principales razones que motivan el cambio del protocolo IP son:

El agotamiento del espacio de direcciones.

Soporte a nuevas aplicaciones.
Mejoramiento de la seguridad

29.4 El camino hacia una nueva versin del IP

El diseo de base elegido para la nueva versin del IP es SIPP (Simple IP Plus). Toma la base
del IP y aade algunas ideas de otras propuestas.

29.5 Nombre del prximo IP

En primera instancia la IAB propuso el nombre de IP versin 7 lo cual trajo confusiones por
el supuesto salto de dos versiones (5 y 6). Para evitar confusin el IETF cambi el nombre a
IP la nueva generacin (IPng).
Luego, tras varias discusiones se decidi llamarlo IPV6.

29.6 Caractersticas del IPV6

IPV6 conserva varias de las caractersticas que hicieron exitoso al IPV4. Algunas son:

Soporta entrega sin conexin.

Permite al emisor seleccionar el tamao de un datagrama.
Solicita al emisor que especifique la cantidad mxima de saltos para la entrega de un
datagrama.
34

Los cambios que introduce IPV6 pueden ser agrupados en cinco categoras:
1. Direcciones ms largas. Se paso de 32 a 128 bits.
2. Formato de encabezado flexible. El encabezado es incompatible con la versin
anterior ya que IPV4 usa un encabezado donde slo las opciones son de tamao
variable.
3. Opciones mejoradas. Se incluyen nuevas opciones que proporcionan capacidades
adicionales no disponibles en IPV4.
4. Soporte de asignacin de recursos. Permite la pre asignacin de recursos de red.
5. Previsin para extensin del protocolo. Se pasa de un protocolo que especifica
TODOS los detalles a otro que puede permitir caractersticas adicionales.

29.8 Forma general de un datagrama IPV6

El formato del datagrama cambia completamente. El encabezado base es de tamao fijo
seguido por posibles encabezados de extensin y luego los datos.

opcional
Extensin 1 de encabezado
Extensin n de encabezado
Encabezado base

DATOS

Figura 29.1

29.8 Formato del encabezado base del IPV6

Cambios en los encabezados de los datagramas:

La alineacin se cambi de mltiplos de 32 bits a mltiplos de 64 bits.

Los campos de longitud de encabezado se eliminaron, y el campo de longitud de
datagrama se cambi por el campo PAYLOAD LENGTH.
Los campos que llevan las direcciones (fuente y destino) se incrementaron a 16 bytes
(128 bits).
La informacin de fragmentacin se ha movido de los campos fijos en el encabezado
base hacia un encabezado de extensin.
El campo TTL se reemplaz por el de HOP LIMIT (limite de saltos)
El campo TOS se cambi por el FLOW LABEL.
El campo protocolo se cambi por un campo que especifica el tipo del prximo
encabezado.

35

16

VERS

31

ETIQUETA DE FLUJO
LONGITUD DE PAYLOAD

PROX. ENCAB.

LIMITE DE SALTOS

DIRECCION DE FUENTE

DIRECCION DE DESTINO

Figura 29.2

29.9 Encabezados de extensin IPV6

La idea de utilizar encabezados de extensin naci para lograr tanto eficiencia como
generalidad. No todas las caractersticas del protocolo son necesarias en todos los
datagramas, por eso es til la capacidad de agregar slo los encabezados necesarios como
encabezados de extensin, que son similares a las opciones de IPV4.

29.10 Anlisis de un datagrama IPV6

Cada encabezado de extensin posee un campo que determina cual ser el siguiente
encabezado (NEXT HEADER).

29.11 Fragmentacin y re ensamblaje del IPV6

En IPV4, si un datagrama es ms grande que el MTU, los routers intermedios podan
fragmentar el datagrama. En cambio en IPV6 la fragmentacin est restringida a la fuente
para liberar a los intermediarios de esta accin. Para esto la fuente utiliza la tcnica MTU
Discovery. La fragmentacin en si es bastante parecida a la de IPV4, ya que hay un campo
que indica el desplazamiento y otro que indica si hay mas fragmentos.
ENCAB. PROX

RESERVADO

DESPLAZAMIENTO DE FRAG.

MF

IDENTIFICACION DE DATAGRAMA
Figura 29.5

29.12 Consecuencia de la fragmentacin de extremo a extremo

La fragmentacin EAE (extremo a extremo) est fomentada por la reduccin de carga para
los routers intermedios, para que justamente estos se dediquen a rutear y no a fragmentar. Sin
embargo esto trae una consecuencia, que es que los routers no puedan cambiar las rutas como
en IPV4 ya que dicha accin puede modificar el tamao del MTU.
Un protocolo de red de redes que use la fragmentacin de EAE requiere que el
emisor descubra el Path MTU para cada destino y que fragmente cualquier
datagrama que salga si es mayor que el Path MTU. La fragmentacin de EAE no
se adapta al cambio de rutas.
Para solucionar el cambio de rutas, si un router intermedio necesita fragmentar un datagrama,
en vez de hacerlo, crea un tnel de IPV6 a travs de IPV6. En vez de modificar el datagrama
original, crea uno completamente nuevo que encapsula el datagrama original como dato.
36

Como resultado, lo que fragmenta es el nuevo datagrama replicando el encabezado base e

insertando un encabezado de extensin en cada fragmento. Luego enva todos los fragmentos
al destino.

29.13 Ruteo de origen del IPV6

Para especificar opciones de ruteo desde el origen, a diferencia de IPV4 que usaba el campo
OPTIONS, IPV6 usa encabezados de extensin. El encabezado de ruteo debe ser el primero
de los encabezados de extensin, y posee un campo NUM ADDRS que especifica la cantidad
de direcciones que componen la ruta y otro NEXT ADDRESS que especifica la direccin
siguiente a la que se enviar el datagrama.

29.14 Opciones del IPV6

Existen adems encabezados de opcin, para que IPV6 se adapte a cualquier tipo de
informacin. Estos encabezados se llaman:

Hop By Hop extension Header

End To End extension Header

Ambos encabezados poseen la misma forma, y se los identifica por un cdigo. El primero de
ellos se examina en cada salto y el otro slo en el destino. Poseen un campo NEXT
HEADER, HEADER LEN (ambos de 1 byte) y OPTIONS (de size variable). Las opciones se
colocan secuencialmente en el campo OPTIONS.

29.15 Tamao del espacio de direccin del IPV6

El espacio de direccionamiento es ENORME. Si las direcciones se asignaran a razn de un
milln de direcciones por milisegundo, haran falta alrededor de 20 aos para asignarlas
todas.

29.16 Notacin hexadecimal con dos puntos del IPV6

Obviamente la notacin en binario no sirve y la decimal usada en IPV4 tampoco.
Ejemplo:
Direccin IPV6 en notacin IPV4
104.230.140.100.255.255.255.255.0.0.17.128.150.10.255.255
Para evitar cadenas tan largas se usa notacin hexadecimal usando los dos puntos como
separador

Ejemplo:
La direccin anterior sera:
68E6:8C64:FFFF:FFFF:0:1180:96A:FFFF
Se pueden expresar cadenas contiguas de 0s con dobles dos puntos.
Ejemplo:
Las siguientes direcciones son equivalentes
FF05:0:0:0:0:0:0:B3 = FF05::B3
Tambin se permite mezclar notaciones para hacer ms amena la transferencia de IPV4 a
IPV6.
Ejemplo:
37

0:0:0:0:0:0:128.10.2.1
El ejemplo anterior tambin se puede comprimir.
Ejemplo:
::128.10.2.1
La compresin de 0s se permite slo una vez en toda la direccin.

29.17 Tres tipos bsicos de direcciones IPV6

La asociacin de direcciones es similar a IPV4. Las direcciones IP determinan una conexin
de red y no una mquina.
La diferencia de IPV6 es que permite que ms de un prefijo sea asignado a una misma red, y
que adems, ms de una direccin sea asignada a una interfaz determinada.
En general, una direccin IP de destino cae entre los siguientes tres grupos:
1. Unidifusin: La direccin de destino especifica una sola computadora
2. Grupo: El destino es un conjunto de computadoras que comparten un prefijo de
direccin.
3. Multidifusin: El destino es un conjunto de computadoras, posiblemente en
mltiples localidades.

29.18 Dualidad de difusin y multidifusin

El IPV6 no emplea difusin o difusin dirigida para referirse a la entrega a todas las
computadoras en una red o una subred IP lgica. En cambio, utiliza el trmino multidifusin,
y trata a la difusin como una forma especial de multidifusin.

29.19 Una eleccin de ingeniera y difusin simulada

COMPLETAR ESTOS ULTIMOS PUNTOS

29.20 Asignacin propuesta de espacio de direccin IPV6

Como dividir el espacio de direcciones es un tema de bastante debate. IPV4 tiene dividido su
espacio segn

29.21 Codificacin y transicin de la direccin IPV4

29.22 Proveedores, suscriptores y jerarqua de direcciones
29.23 Jerarqua adicional

38

Apndice 1 IPsec
A.1.1 Qu es IPsec?
IPsec es una extensin al protocolo IP que proporciona seguridad a IP y a los protocolos de
capas superiores. Fue desarrollado para el nuevo estndar IPV6 y despus fue portado a
IPV4.
Sirve para asegurar la autenticacin, integridad y confidencialidad de la comunicacin.
Posee dos modos:
1. Modo Tnel
2. Modo Transporte
En modo tnel el datagrama IP se encapsula completamente dentro de un nuevo datagrama IP
que emplea el protocolo IPsec.
En modo transporte IPsec slo maneja la carga del datagrama IP, insertndose la cabecera
IPsec entre la cabecera IP y la cabecera del protocolo de capas superiores (ver Figura a.1.1).

Modo transporte

IP

Paquete original

Modo tnel

IP

Nuevo header IP

AH

AH

TCP

DATA

IP

TCP

DATA

IP

TCP

DATA

Figura a.1.1

A.1.2 Los protocolos IPsec

La familia de protocolos IPsec est formada por dos protocolos:

1. AH (Authentication Header).
2. ESP (Encapsulated Security Payload).

Ambos son protocolos IP independientes. AH es el protocolo IP 51 y ESP el protocolo IP 50.

39

A.1.2.1 Cabecera de autenticacin AH

El protocolo AH protege la integridad del datagrama IP. Para conseguirlo, calcula una
HMAC (Hash-based Message Authentication Code) basada en la clave secreta, el contenido
del paquete y las partes inmutables de la cabecera IP (como son las direcciones IP). Tras esto,
aade la cabecera AH al paquete (Ver Figura a.1.2).
8
Next Header

16
Payload Length

Reserved

Security Parameter Index (SPI)

Sequence Number
Hash Message Authentication Code
Figura a.1.2

La cabecera AH mide 24 bytes. El primer byte es el campo Siguiente cabecera. Este

campo especifica el protocolo de la siguiente cabecera.
o En modo tnel se encapsula un datagrama IP completo, por lo que el valor de
este campo es 4.
o Al encapsular un datagrama TCP en modo transporte, el valor correspondiente
es 6.
El siguiente byte especifica la longitud del contenido del paquete. Este campo est
seguido de dos bytes reservados.
Los siguientes 4 bytes especifican en ndice de Parmetro de Seguridad (SPI). El SPI
especifica la asociacin de seguridad (SA) a emplear para el desencapsulado del
paquete.
El Nmero de Secuencia de 32 bit protege frente a ataques por repeticin.
Finalmente, los ltimos 96 bit almacenan el cdigo de resumen para la autenticacin
de mensaje (HMAC). Este HMAC protege la integridad de los paquetes ya que slo
los miembros de la comunicacin que conozcan la clave secreta pueden crear y
comprobar HMACs.

Como el protocolo AH protege la cabecera IP incluyendo los aportes inmutables de la

cabecera IP como las direcciones IP, el protocolo AH no permite NAT. Tras el intercambio, la
HMAC ya no es vlida. La extensin a IPsec NAT-transversal implementa mtodos que
evitan esta restriccin.

A.1.2.2 Carga de Seguridad Encapsulada ESP

El protocolo ESP puede asegurar la integridad del paquete empleando una HMAC y la
confidencialidad empleando cifrado. La cabecera ESP se genera y aade al paquete tras
cifrarlo y calcular su HMAC. La cabecera ESP consta de dos partes (Ver Figura a.1.3).

40

Security Parameter Index (SPI)

Sequence Number
Initialization Vector

DATA

Padding

Padding Length

Next Header

Hash Message Authentication Code

Figura a.1.3

Los primeros 32 bits de la cabecera ESP especifican el ndice de Parmetros de

Seguridad (SPI). Este SPI especifica qu SA emplear para desencapsular el paquete
ESP.

Los siguientes 32 bits almacenan el Nmero de Secuencia. Este nmero de secuencia

se emplea para protegerse de ataques por repeticin de mensajes.

Los siguientes 32 bits especifican el Vector de Inicializacin (IV - Initialization

Vector) que se emplea para el proceso de cifrado. Los algoritmos de cifrado simtrico
pueden ser vulnerables a ataques por anlisis de frecuencias si no se emplean IVs. El
IV asegura que dos cargas idnticas generan dos cargas cifradas diferentes.

IPsec emplea cifradores de bloque para el proceso de cifrado. Por ello, puede ser
necesario rellenar la carga del paquete si la longitud de la carga no es un mltiplo de
la longitud del paquete (Padding). En ese caso se aade a continuacin la longitud del
relleno (Padding length).

Tras la longitud del relleno se coloca el campo de 2 bytes Siguiente cabecera que
especifica la siguiente cabecera.

Por ltimo, se aaden los 96 bit de HMAC para asegurar la integridad del paquete.
Esta HMAC slo tiene en cuenta la carga del paquete: la cabecera IP no se incluye
dentro de su proceso de clculo.

El uso de NAT, por lo tanto, no rompe el protocolo ESP. Sin embargo, en la mayora
de los casos, NAT an no es compatible en combinacin con IPsec. NAT-Transversal
ofrece una solucin para este problema encapsulando los paquetes ESP dentro de
paquetes UDP.

41

42

Apndice 2 Protocolo IKE

A.2.1 Para que sirve IKE?
El protocolo IKE (Internet Key Exchange) resuelve el problema ms importante del
establecimiento de comunicaciones seguras: la autenticacin de los participantes y el
intercambio de claves simtricas, tras ello, crea las asociaciones de seguridad.

A.2.2 Caractersticas de IKE

Suele implementarse a travs de servidores de espacio de usuario, y no suele

implementarse en el sistema operativo.
Emplea el puerto 500 UDP para su comunicacin.
Funciona en dos fases.
1. La primera fase establece un ISAKMP SA (Internet Security Association Key
Management Security Association).
2. En la segunda fase, el ISAKMP SA se emplea para negociar y establecer las SAs
(Security Asociations) de IPsec.

A.2.3 Fases de IKE

La primer fase suele soportar dos modos distintos:
1. Modo principal
2. Modo agresivo.
Ambos modos autentican al participante en la comunicacin y establecen un ISAKMP SA,
pero el modo agresivo slo usa la mitad de mensajes para alcanzar su objetivo. Esto, sin
embargo, tiene sus desventajas, ya que el modo agresivo no soporta la proteccin de
identidades y, por lo tanto, es susceptible a un ataque man-in-the-middle (por escucha y
repeticin de mensajes en un nodo intermedio) si se emplea junto a claves compartidas con
anterioridad (PSK Pre Shared Keys). Pero sin embargo este es el nico objetivo del modo
agresivo, ya que los mecanismos internos del modo principal no permiten el uso de distintas
claves compartidas con anterioridad con participantes desconocidos. El modo agresivo no
permite la proteccin de identidades y transmite la identidad del cliente en claro. Por lo tanto,
los participantes de la comunicacin se conocen antes de que la autenticacin se lleve a cabo,
y se pueden emplear distintas claves pre-compartidas con distintos comunicantes.
En la segunda fase, el protocolo IKE intercambia propuestas de asociaciones de seguridad y
negocia asociaciones de seguridad basndose en la ISAKMP SA.
La ISAKMP SA proporciona autenticacin para protegerse de ataques man-in-the-middle.
Esta segunda fase emplea el modo rpido.
Normalmente, dos participantes de la comunicacin slo negocian una ISAKMP SA, que se
emplea para negociar varias (al menos dos) IPsec SAs unidireccionales.

43

Apndice 3 NAT
(Network Address Translation)
A.3.1 Qu es NAT?
Es un mecanismo utilizado por routers IP para intercambiar paquetes entre dos redes que se
asignan mutuamente direcciones incompatibles. Consiste en convertir en tiempo real las
direcciones utilizadas en los paquetes transportados. Tambin es necesario editar los paquetes
para permitir la operacin de protocolos que incluyen informacin de direcciones dentro de
la conversacin del protocolo.
Su uso ms comn es permitir utilizar direcciones privadas para acceder a Internet. Existen
rangos de direcciones privadas que pueden usarse libremente y en la cantidad que se quiera
dentro de una red privada. Si el nmero de direcciones privadas es muy grande puede usarse
solo una parte de direcciones pblicas para salir a Internet desde la red privada. De esta
manera simultneamente slo pueden salir a Internet con una direccin IP tantos equipos
como direcciones pblicas se hayan contratado. Esto es necesario debido al progresivo
agotamiento de las direcciones IPV4. Se espera que con el advenimiento de IPV6 no sea
necesario continuar con esta prctica.

A.3.2 Funcionamiento
Una pasarela NAT cambia la direccin origen en cada paquete de salida y, dependiendo del
mtodo, tambin el puerto origen para que sea nico. Estas traducciones de direccin se
almacenan en una tabla, para recordar qu direccin y puerto le corresponde a cada
dispositivo cliente y as saber donde deben regresar los paquetes de respuesta. Si un paquete
que intenta ingresar a la red interna no existe en la tabla de traducciones, entonces es
descartado.
Debido a este comportamiento, se puede definir en la tabla que en un determinado puerto y
direccin se pueda acceder a un determinado dispositivo, como por ejemplo un servidor web,
lo que se denomina NAT inverso o DNAT (Destination NAT).
NAT tiene muchas formas de funcionamiento, entre las que destacan:

Esttico
Dinmico
Sobrecarga
Solapamiento

A.3.2.1 Esttico
Es un tipo de NAT en el que una direccin IP pblica se traduce a una direccin IP privada, y
donde esa direccin pblica es siempre la misma. Esto le permite a un host, como un servidor
Web, tener una direccin IP de red privada pero an as ser visible en Internet.

A.3.2.2 Dinmico
Es un tipo de NAT en la que una direccin IP privada se mapea a una IP pblica basndose en
una tabla de direcciones de IP pblicas registradas. Normalmente, el router NAT en una red
mantendr una tabla de direcciones IP registradas, y cuando una IP privada requiera acceso a
Internet, el router elegir una direccin IP de la tabla que no est siendo usada por otra IP
privada. Esto permite aumentar la seguridad de una red dado que enmascara la configuracin
interna de una red privada, lo que dificulta a los hosts externos de la red el poder ingresar a
44

sta. Para este mtodo se requiere que todos los hosts de la red privada que deseen conectarse
a la red pblica posean al menos una IP pblica asociada.

A.3.2.3 Sobrecarga
La forma ms utilizada de NAT, proviene del NAT dinmico, ya que toma mltiples
direcciones IP privadas (normalmente entregadas mediante DHCP) y las traduce a una nica
direccin IP pblica utilizando diferentes puertos. Esto se conoce tambin como PAT (Port
Address Translation), NAT de nica direccin o NAT multiplexado a nivel de puerto.

A.3.2.4 Solapamiento
Cuando las direcciones IP utilizadas en la red privada son direcciones IP pblicas en uso en
otra red, el router posee una tabla de traducciones en donde se especifica el reemplazo de
stas con una nica direccin IP pblica. As se evitan los conflictos de direcciones entre las
distintas redes.

45

Apndice 4 HTTP
(RFC 2616, 2068)
A.4.1 Que es HTTP?
HTTP (Hyper Text Transport Protocol) es un protocolo de capa de aplicacin que fue creado
por el World Wide Web Consortium y es utilizado en cada transaccin a travs de Internet. En
un principio era limitado y no soportaba encabezados, por lo tanto no posea el comando
POST con lo cual solo era posible enviar poca informacin al servidor a travs del comando
GET.

A.4.2 El protocolo segn las versiones

Versin 0.9:
Solo soporta el comando GET
Permita transmitir texto plano
Versin 1.0
Permite mas opciones de transferencia
Datos con formato MIME.
Metodos Get, Post y Head.
Modifica la sintaxis de la peticin y de la respuesta.
Versin 1.1
Necesidades de los sistemas intermedios
Necesidades de persistencia de la conexin.
Metodos: Get, Post, Head, Options, Put, Delete, Trace, Patch, etc.

A.4.3 Caractersticas del protocolo

Algunas caractersticas importantes del protocolo son:

Es un protocolo stateless, es decir que no presenta estados por lo cual no guarda

informacin de conexiones anteriores.
Es orientado a transacciones. Esquema de consulta / respuesta. El cliente, quien inicia
la transaccin, se denomina user agent. El servidor, quien posee el recurso, es quien
realiza la respuesta.
Es flexible en cuanto a los formatos.
Es robusto.
Se implementa sobre TCP / IP para brindar seguridad.
Utiliza un cache.

A.4.4 Definiciones relacionadas con el protocolo

Cliente: Un programa de aplicacin que establece conexiones con el propsito de

enviar peticiones.
Conexin: Circuito virtual de la capa de transporte establecido entre dos programas
de aplicacin con propsitos de comunicacin.
Entidad: Una representacin de un recurso de datos que puede estar incluido dentro
de un mensaje de peticin o respuesta. Una entidad consiste de cabeceras y un cuerpo.
Mensaje: Es la unidad bsica de comunicacin HTTP.

A.4.5 Sistemas intermedios

El protocolo acepta sistemas intermedios. Se definen a continuacin:

46

Cache: Es un almacenamiento local que sirve para reducir el tiempo de respuesta y el

consumo de ancho de banda en peticiones futuras. Puede ser implementado tanto en
el cliente como en el servidor, aunque un servidor no puede utilizar un cache cuando
acta como tnel. No todas las operaciones pueden cachearse (Ej. Validacin de
usuario y password).
Gateway (Pasarela): Se trata de un servidor que trabaja como intermediario para
otros servidores, que recibe peticiones como si fuera el servidor original del recurso
solicitado. Se usa cuando hay un firewall del lado del servidor y cuando hay que
hacer traducciones de protocolos cmo FTP HTTP.
Proxy (Representante): Es un programa intermedio que trabaja tanto como un
servidor como un cliente. Debe interpretar y/o reescribir un mensaje de peticin antes
de reenviarlo. Se usa cuando hay un firewall del lado del cliente, o hay diferentes
versiones de HTTP.
Tnel: Es un programa intermedio que trabaja como transmisor ciego entre dos
conexiones. No se considera como parte de la comunicacin HTTP. Un tnel se cierra
cuando los dos extremos de la conexin transmitida se cierran. Se usa cuando hay un
firewall del lado del cliente o del servidor. Se establece una conexin autenticada, que
luego se usa solo para HTTP.

A.4.6 Mtodos de peticin existentes

GET: para pedir informacin identificada por una URL.
PUT: peticin para aceptar la entidad incorporada y almacenarla bajo la URL proporcionada.
DELETE: solicita que el servidor origen suprima el recurso identificado por la URL.
POST: una peticin para aceptar la entidad incorporada como una nueva subordinada al URL
identificado.
LINK: establece una o ms relaciones de enlace entre recursos identificados.
PATCH: es similar a put salvo que la entidad contiene una lista de diferencias respecto al
contenido del recurso original.
UNLINK: elimina una o ms relaciones de enlace entre recursos.
COPY: solicita una copia del recurso identificado por la URL.
TRACE:
HEAD: es idntica a GET salvo que la respuesta del servidor no debe incluir un cuerpo de
entidad.
MOVE: solicita que el recurso identificado por la URL se mueva a la localizacin dada en el
campo cabecera-URL en la cabecera entidad.
OPTIONS: para pedir las opciones disponibles para la cadena peticin/respuesta identificada
por la URL.
WRAPPED: permite a un cliente enviar una o ms solicitudes encapsuladas.

A.4.7 Identificacin de recursos

Para identificar el recurso con el que se desea trabajar se usa la URI (Uniform
Resource Identifier) o la URL (Uniform Resource Locator).
Es una cadena de caracteres que identifica el recurso que est disponible.
Sintaxis de la URL:
o Protocolo: // Host : Puerto/ ruta ? Parmetro = valor # Enlace

A diferencia de la URL, la URI no especifica el protocolo.

A.4.8 Mensajes de respuesta

47

A.4.9 Cabeceras HTTP

48

Apndice 5 PAT
(Port Address Translation)
A.5.1 Qu es PAT?
Es una caracterstica del estndar NAT, que traduce conexiones TCP y UDP hechas por un
host y un puerto en una red externa a otra direccin y puerto de la red interna. Permite que
una sola direccin IP sea utilizada por varias mquinas de la intranet. Con PAT, una IP
externa puede responder hasta a ~64000 direcciones internas.
Cualquier paquete IP contiene la direccin y el puerto tanto del origen como del destino. En
el destino, el puerto le dice al receptor cmo procesar el paquete. Un paquete con puerto 80
indica que contiene una pgina web, mientras que el puerto 25 es usado para transmitir
correo electrnico entre servidores de correo. La traduccin de los puertos, llamada PAT para
distinguirla de la traduccin de direcciones (NAT), se apoya en el hecho de que el puerto de
origen carece de importancia para la mayora de los protocolos. Igual que NAT, se sita en la
frontera entre la red interna y externa, y realiza cambios en la direccin del origen y del
receptor en los paquetes de datos que pasan a travs de ella. Los puertos (no las IP), se usan
para designar diferentes hosts en el intranet.
El servicio PAT es como una oficina de correo que entrega las cartas. Los sobres
que salen son modificados para que el remitente sea la oficina de correos,
mientras que las cartas que llegan de afuera pierden su direccin y reciben la
nueva con la calle y el nmero real.

A.5.2 Procedimiento PAT

Cuando un ordenador de la intranet manda un paquete hacia fuera, queremos ocultar

su direccin real. El servicio NAT remplaza la IP interna con la nueva IP del propio
servicio.
Luego asigna a la conexin un puerto de la lista de puertos disponibles, inserta el
puerto en el campo apropiado del paquete de datos y enva el paquete.
El servicio NAT crea una entrada en su tabla de direcciones IP internas, puertos
internos y puertos externos. A partir de ese entonces, todos los paquetes que
provengan del mismo host sern traducidos con los mismos puertos.
El receptor del paquete utilizar los IP y puerto recibidos para responder, por lo que
dicha respuesta llegar a la oficina de correos.
Si el puerto destino no existe en la tabla del NAT, los datos sern descartados.
En otro caso, la nueva direccin y el nuevo puerto reemplazarn los datos de destino
en el paquete y ste ser enviado por la red interna.
La traduccin de puertos permite a varias mquinas compartir una nica direccin IP.
El servicio PAT borra las traducciones peridicamente de su tabla cuando aparenten
no estar en uso. Como el nmero de posibles puertos a otorgar es de 16 bit (65535), la
probabilidad de que un ordenador no encuentre una traduccin es realmente pequea.

49

Apndice 6 BGP
(Border Gateway Protocol) RFC 1771
A.6.1 Introduccin
BGP es un protocolo de routing externo. Los protocolos de routing externo son los que se
utilizan para interconectar sistemas autnomos. En los protocolos de routing externo la
prioridad es buscar rutas ptimas atendiendo nicamente al criterio de minimizar la distancia
medida en trminos de la mtrica elegida para la red.
Hasta 1990 se utilizaba como protocolo de routing externo en Internet el denominado EGP
(Exterior Gateway Protocol). Este protocolo no fue capaz de soportar el crecimiento de la red
y entonces se desarrollo un nuevo protocolo de routing externo denominado BGP. Desde
entonces se ha producido 4 versiones de BGP, las especificaciones ahora vigentes de BGP-4
se encuentran en el RFC 1771.
BGP es un protocolo de transporte fiable. Esto elimina la necesidad de llevar a cabo la
fragmentacin de actualizacin explcita, la retransmisin, el reconocimiento, y
secuenciacin.

A.6.2 Funciones de BGP

BGP se diseo para permitir la cooperacin en el intercambio de informacin de
encaminamiento entre dispositivos de encaminamiento, llamados pasarelas, en sistemas
autnomos diferentes. El protocolo opera en trminos de mensajes, que se envan utilizando
TCP.

A.6.3 Mensajes de BGP

OPEN: sirve para adquirir un vecino. Un dispositivo de encaminamiento abre

primero una conexin TCP con el vecino y despus enva un OPEN.

UPDATE: facilita dos tipos de informacin:

o Informacin sobre una ruta particular a travs del conjunto de redes. Esa
informacin se puede incorporar a la base de datos de cada dispositivo de
encaminamiento que la recibe.
o Una lista de rutas previamente anunciadas por este dispositivo de
encaminamiento que van a ser eliminadas

KEEPALIVE: consta solo de la cabecera. Cada dispositivo de mantenimiento enva

regularmente estos mensajes para evitar que expire el temporizador mantenimiento.

NOTIFICATION: se envan cuando se detecta algn tipo de error.

A.6.4 Procedimientos funcionales de BGP

BGP posee tres procedimientos funcionales principales:
1. Adquisicin de vecino.
2. Deteccin de vecino alcanzable.
3. Deteccin de red alcanzable.

A.6.4.1 Adquisicin de vecino

Dos dispositivos de encaminamiento se consideran vecinos si estn en la misma subred. Si
los dos dispositivos de encaminamiento estn en sistemas autnomos, podran desear
intercambiar informacin de encaminamiento. Para este cometido es necesario realizar
primero el proceso de adquisicin de vecino.
50

Para llevar a cabo la adquisicin de vecino, un dispositivo enva al otro un mensaje OPEN. Si
el otro dispositivo acepta la relacin, enva un mensaje KEEPALIVE.

A.6.4.2 Deteccin de vecino alcanzable

Una vez establecida la relacin de vecino, se utiliza el procedimiento de deteccin de vecino
alcanzable para mantener la relacin. Este procedimiento consiste en enviarse entre los dos
vecinos peridicamente mensajes de KEEPALIVE para asegurarse de que la relacin sigue
establecida.

A.6.4.3 Deteccin de red alcanzable

El ltimo procedimiento especificado por BGP es la deteccin de red alcanzable. Cada
dispositivo de encaminamiento mantiene una base de datos con las redes que puede alcanzar
y la ruta preferida para llegar hasta esa red. Siempre que se realiza un cambio en esa base de
datos, el dispositivo de almacenamiento enva un mensaje de UPDATE por difusin a todos
los dispositivos de encaminamiento que implementan BGP.

51

Apndice 7 RSVP
(RFC 2205)
A.7.1 Qu es RSVP?
Protocolo de reserva de recursos (RSVP) es una tcnica de sealizacin que se utiliza para
garantizar la calidad de servicio (QoS) reservar ancho de banda para flujos de datos
compatibles con RSVP. Todos los nodos de la ruta de acceso a datos deben ser compatibles
con RSVP para una garanta de QoS. Las reservas son iniciado receptor para trfico
multidifusin y unidifusin.

A.7.2 Caractersticas de RSVP

La reserva es realizada por flujo.

Es un protocolo de sealizacin.
Es un protocolo de la capa de transporte.
RSVP no es un protocolo de encaminamiento, pero trabaja con protocolos de
enrutamiento actuales.
RSVP est orientada hacia el receptor: es el receptor de un flujo de datos el que inicia
y mantiene la reserva de recursos para ese flujo.
RSVP es Soft State, es decir que mantiene solo temporalmente el estado de las
reservas de recursos del host y de los routers, de aqu que soporte cambios dinmicos
de la red.
RSVP debe mantener en cada nodo los requerimientos de reserva (se define el Soft
State).
La reserva en cada nodo necesita refresco peridico.
RSVP proporciona varios estilos de reserva (un conjunto de opciones) y permite que
se aadan futuros estilos al protocolo para permitirle adaptarse a diversas
aplicaciones.

A.7.3 Qu es el Soft State?

Son los estados en los router y hosts extremos, refrescados por los mensajes Path y Resv.

A.7.4 Los mensajes de RSVP

52

Referencias

Redes Globales de Informacion con Internet y TCP /IP Tercera Edicion.

Douglas E. Commer

Comunicaciones y Redes de William Stallings

Wikipedia

53

Acrnimos

EAE: Extremo a extremo.

SW: Software.

54

HW: Hardware.Dudas
Diferencia entre difusin por direccin de HW y difusin IP

Temas
BGP
bootp
dhcp
nat
pat
proxy
gateway
firewall
tunel
dmz
ftp
tftp
rsvp
ipv6
ipsec
seguridad
IKE
telnet
dns
http
smtp
mime
ISA
DSA

55