%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                       Legal Notice                            %
%                                                               %
% This document is copyright by Olaf Kirch, okir@monad.swb.de   %
%                                                               %
% For copying conditions, please refer to the file COPYING.     %
%                                                               %
% The author is not liable for any damages, direct or indirect, %
% resulting from the use of information provided in this        %
% document.                                                     %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% When viewing this document with vi on an 80-columns screen,   %
% do a ':se nonumber' first.                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Revisado en 4-Febrero-1999 por:                               %
%   Juan Jose Amor <jjamor@ls.fi.upm.es>                        %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% START OF CHAPTER                                              %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Introducci\'on a las Redes}
\label{intro}

% *  Introduction. Idle chit-chat on networking in
%    general. (Being worked upon)
%
%    *  Different concepts of networking: LANs, store-and-forward
%       networks (UUCP), Internetworking. A rough sketch of address
%       resolution and routing in any of these.
%
%    *  Back To Basics: The OSI reference model; layers. The way
%       it's handled in the ARPAnet: IP-addresses and routing.
%       Datagrams vs. streams. Ports and well-known services.
%       The BSD socket library (incl. AF\_UNIX sockets?).
%       The way UUCP does it.
%
% * TCP/IP networking
%
%    *  IP addresses and routing
%
%    *  The domain name system. More on name servers, resolvers,
%       queries. Resource records in the DNS database.
%
%    *  Example. I would like to construct a 'standard' situation
%       throughout the manual that might serve as a reference 
%       for people on a UUCP network as well as a LAN.

\section{Historia}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Cavemen and the ARPANET                                       %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.history}
% \index{Picapiedra, Pedro}

La idea de red es probablemente tan vieja como la de las telecomunicaciones.
Consideremos a la gente que viv\'{\i}a en la edad de piedra, donde los tambores se
habr\'{\i}an utilizado para transmitir mensajes entre individuos. Suponga que el
cavern\'{\i}cola A quiere invitar al cavern\'{\i}cola B a un partido de lanzamiento de
rocas contra el otro, pero viven demasiado lejos como para que B oiga a A
golpear su tambor. ?`Cu\'ales son las opciones de A? Podr\'{\i}a 1)~ir a la choza de
B, 2)~hacerse con un tambor m\'as grande, o 3)~pedirle a C, que vive a mitad
de camino entre los dos, que retransmita el mensaje. La \'ultima opci\'on es
lo que se llama una red.

Claro, que ya ha pasado un tiempo desde los primeros intentos
de nuestros antepasados. Hoy en d\'{\i}a tenemos ordenadores 
que hablan entre s\'{\i} a trav\'es de vastas conexiones de cables, fibras 
\'opticas, microondas, y otros medios parecidos, para quedar para el 
partido del sabado. A continuaci\'on trataremos sobre las maneras
en que esto se realiza, pero olvid\'andonos de los cables, 
as\'{\i} como de la parte del partido.


En esta Gu\'{\i}a escribiremos sobre dos tipos de redes : las basadas en UUCP, y las 
basadas en TCP/IP. \'Estos son conjuntos de protocolos y paquetes de 
software que proporcionan medios para transportar datos entre dos 
ordenadores. En este cap\'{\i}tulo veremos ambos tipos y
discutiremos sus principios fundamentales.

\index{red}
\index{site}
\index{nodo}

Definiremos una red como un conjunto de \emph{nodos} que son capaces de 
comunicarse entre s\'{\i}, a menudo contando con los servicios de varios
nodos especializados que conmutan datos entre los participantes. Los nodos suelen 
ser ordenadores, aunque no es necesario; podemos considerar tambi\'en 
terminales~X o impresoras inteligentes como nodos. Peque\~nas 
aglomeraciones de nodos tambi\'en se llaman \emph{instalaciones}.\footnote{
N. del T.: Del ingl\'es \emph{site}
}

\index{red!protocolos}
\index{protocolo}
La comunicaci\'on ser\'{\i}a imposible sin alg\'un tipo de lenguaje o c\'odigo. En las
redes de ordenadores, estos lenguajes son llamados colectivamente 
\emph{protocolos}. Sin embargo, no deber\'{\i}a pensar en protocolos escritos, 
sino m\'as bien en el c\'odigo de comportamiento altamente formalizado que se 
observa cuando se encuentran los jefes de estado. De un modo 
muy similar, los protocolos usados por las redes de ordenadores no son 
sino normas muy estrictas para el intercambio de mensajes entre dos o mas 
nodos.


\section{Redes UUCP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Introduccion a redes UUCP                                     %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.uucp}
\index{red!UUCP|see {UUCP}}
\index{UUCP|(}

UUCP es una abreviatura de Unix-to-Unix Copy (Copia de Unix a Unix). 
Comenz\'o siendo un paquete de programas para transferir ficheros sobre 
l\'{\i}neas serie, programar esas transferencias, e iniciar la ejecuci\'on de 
programas en el lugar remoto. Ha experimentado grandes cambios desde su 
primera implementaci\'on a finales de los setenta, pero aun es bastante 
espartano en los servicios que ofrece. Su principal aplicaci\'on es todav\'{\i}a 
en redes de \'area metropolitana (WAN) basadas en enlaces telef\'onicos.


% UUCP-based networks
% are of the store-and-forward variety, which means that the physical
% links between forwarding hosts are activated at certain intervals only
% (usually several times a day), so that any data has to be stored
% temporarily.

%\footnote{
% In the UUCP world, most sites consist of one host,
% but it might also be a LAN with one computer handling the UUCP link
% to the outside world. Such sites are most often managed in a way to
% appear as a monolithic system to the outside world.
%}

UUCP comenz\'o a desarrollarse por los Laboratorios Bell en 1977 para la 
comunicaci\'on entre sus laboratorios de desarrollo de Unix. A mediados de 1978, 
esta red ya conectaba a m\'as de 80 centros. Se ejecutaban aplicaciones de 
correo electr\'onico, as\'{\i} como de impresi\'on remota; sin embargo, el uso principal 
del sistema era distribuir software nuevo y mejoras.\footnote{ No parece 
que con el tiempo haya cambiado mucho esto\ldots}
Hoy d\'{\i}a, UUCP ya no est\'a 
confinado en el entorno \unix{}. Hay versiones comerciales disponibles 
para diversas plataformas, incluyendo AmigaOS, DOS, TOS de Atari, etc.


Una de las principales desventajas de las redes UUCP es su bajo ancho de 
banda. Por un lado, el equipo telef\'onico establece un l\'{\i}mite r\'{\i}gido en la 
tasa m\'axima de transferencia. Por otro lado, los enlaces UUCP raramente 
son conexiones permanentes; en su lugar, los nodos se llaman entre 
s\'{\i} a intervalos regulares. Es por ello, que la mayor\'{\i}a del tiempo que le 
lleva a un mensaje viajar por una red UUCP permanece atrapado en el disco 
de alg\'un nodo, esperando al establecimiento de la pr\'oxima conexi\'on.


A pesar de estas limitaciones, a\'un hay muchas redes UUCP funcionando en 
todo el mundo, utilizado principalmente por aficionados, ya que ofrecen acceso 
de red a usuarios privados a precios razonables. La raz\'on fundamental de 
la popularidad del UUCP es que es barat\'{\i}simo comparado con tener el 
ordenador conectado al Gran Cable de Internet. Para hacer de su ordenador 
un nodo UUCP, todo lo que necesita es un m\'odem, software
UUCP, y otro nodo UUCP que desee suministrarle correo y noticias.


\subsection{C\'omo usar UUCP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.uucp.howto}

La idea que hay detr\'as de UUCP es bastante simple: como su nombre indica, 
b\'asicamente copia ficheros de un nodo a otro, pero tambi\'en permite 
realizar ciertas acciones en el nodo remoto.


\index{remoto!ejecuci\'on}
Suponga que le est\'a permitido que su m\'aquina acceda a un nodo hipot\'etico 
llamado \host{swim}, y le va ha hacer ejecutar el comando de 
impresi\'on \prog{lpr} para Ud. Entonces, podr\'{\i}a escribir lo siguiente en 
su l\'{\i}nea de comandos para que le imprima este libro en 
\host{swim}:\footnote{
 Si usa \prog{bash}, la shell GNU Bourne Again SHell, tendr\'{\i}a que quitar 
 los signos de exclamaci\'on, porque los usa como su car\'acter de hist\'orico.
}

\begin{tscreen}
 \$ uux -r swim!lpr !netguide.dvi
\end{tscreen}


Esto hace que \prog{uux}, un comando del repertorio UUCP, planifique un 
\emph{trabajo} para \host{swim}. Este trabajo consta del fichero de 
entrada, \file{netguide.dvi}, y la petici\'on de enviar este fichero a 
\prog{lpr}. La opci\'on \option{-r} indica a \prog{uux} que no llame al 
sistema remoto inmediatamente, sino que almacene el trabajo hasta que se 
establezca la pr\'oxima conexi\'on. A esto se le llama 
\emph{spooling}, o almacenamiento en la cola.


\index{remoto!acceso a ficheros}
Otra propiedad de UUCP es que permite reenviar trabajos y ficheros a
trav\'es de varios nodos, suponiendo que \'estos colaboren. Asumiremos que 
\host{swim}, el nodo del ejemplo anterior, tiene un enlace UUCP con 
\host{groucho}, el cual mantiene un gran n\'umero de aplicaciones \unix{}.
Para transferir el fichero \file{tripwire-1.0.tar.gz} hasta su m\'aquina 
deber\'{\i}a indicarlo as\'{\i}:

\begin{tscreen}
 \$ uucp -mr swim!groucho!\~{}/security/tripwire-1.0.tar.gz trip.tgz
\end{tscreen}


\index{UUCP!reenv\'{\i}o}
\index{reenv\'{\i}o!UUCP}
El trabajo creado pedir\'a a \host{swim} que traiga el fichero desde 
\host{groucho}, y lo env\'{\i}e hasta su m\'aquina, donde UUCP lo almacenar\'a en
\file{trip.tgz} y le notificar\'a por correo la llegada del fichero. Esto
ocurrir\'a en tres pasos. Primero, su m\'aquina env\'{\i}a el trabajo a 
\host{swim}. La siguiente vez que \host{swim} establezca contacto con
\host{groucho}, se transferir\'a el fichero de \host{groucho} a 
\host{swim}. El \'ultimo paso es la transferencia del mismo desde 
\host{swim} hasta su m\'aquina.


Los servicios m\'as importantes que proporcionan las redes UUCP hoy en d\'{\i}a
son el correo electr\'onico y las noticias. Lo introduciremos brevemente
y despu\'es lo veremos en m\'as detalle.


El correo electr\'onico~-- {\it e-mail}\footnote{En
el idioma castellano comienzan a aparecer adaptaciones más o menos afortunadas,
como {\it e-milio}} para abreviar~-- le permite intercambiar
mensajes con usuarios de nodos remotos sin tener realmente que saber
c\'omo acceder a estos nodos. La tarea de dirigir un mensaje desde su
m\'aquina destino la realiza enteramente el sistema de manejo de
correo. En un entorno UUCP, el correo generalmente se transporta
ejecutando el comando \prog{rmail} en el nodo vecino, pas\'andole la
direcci\'on del receptor y el mensaje. \prog{rmail} reenviar\'a entonces el
mensaje a otro nodo, y seguir\'a as\'{\i}, hasta que alcance el nodo destino.
Veremos esto en detalle en el cap\'{\i}tulo~\ref{mail}.


La mejor forma de definir el servicio de noticias es considerarlo como 
un sistema de tabl\'on de 
anuncios distribuido. Muy a menudo, este t\'ermino se refiere a las 
noticias de Usenet, que es, con mucho, la m\'as conocida red de 
intercambio de noticias, con un n\'umero de nodos participantes estimado 
en 120.000\footnote{Teniendo en cuenta que hace tiempo que se escribi\'o 
este libro, es seguro que son muchos m\'as.}. Los or\'{\i}genes de Usenet se 
remontan a 1979, cuando, tras la aparici\'on del UUCP con el nuevo Unix~V7, 
tres estudiantes graduados tuvieron la idea de un intercambio de 
informaci\'on general entre la comunidad Unix. \'Estos escribieron algunos 
scripts, creando el primer sistema de noticias en
red. En 1980, esta red conectaba \host{duke}, \host{unc}, y \host{phs}, y 
dos Universidades de Carolina del Norte, de forma aislada. Usenet creci\'o 
m\'as todav\'{\i}a posteriormente. Aunque su origen fue como una red basada en UUCP, ya no est\'a limitada a un \'unico tipo de redes.


La unidad b\'asica de informaci\'on es el {\it art\'{\i}culo}, que puede ser enviado a 
una jerarqu\'{\i}a de grupos de noticias dedicadas a temas espec\'{\i}ficos. La 
mayor\'{\i}a de los nodos reciben \'unicamente una selecci\'on de todos los 
grupos de noticias, que transportan una media de 60Mb\footnote{De nuevo 
son datos no actualizados} de art\'{\i}culos por d\'{\i}a.


En el mundo UUCP, las noticias generalmente se env\'{\i}an a trav\'es de un 
enlace UUCP, recolectando todos los art\'{\i}culos de los grupos de noticias 
solicitados, y empaquetandolos en varios \emph{lotes}\footnote{N. del T.: Del
ingl\'es \emph{batches}}. \'Estos se 
env\'{\i}an al lugar receptor, donde se pasan al comando \prog{rnews} que los
desempaqueta y procesa posteriormente.


Finalmente, UUCP es tambi\'en el medio elegido por muchos servidores de 
ficheros que ofrecen acceso p\'ublico. Generalmente podr\'a acceder a ellos 
llamando con UUCP, accediendo como usuario invitado, y transferi\'endose 
los archivos desde un \'area de ficheros p\'ublicamente accesible. Estas 
cuentas de invitado tienen, a menudo, un nombre de acceso y password como 
UUCP/nuucp o algo similar.

\index{UUCP|)}

\section{Redes TCP/IP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Intro to TCP/IP networks                                      %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip}
\index{red!TCP/IP|see {TCP/IP}}
\index{TCP/IP|(}
\index{Redes de Area Local|see {LAN}}
\index{LAN}

Aunque UUCP puede resultar una elecci\'on razonable para enlaces de red 
mediante llamada de bajo coste, hay muchas situaciones en las que su 
t\'ecnica de almacenamiento y reenv\'{\i}o se muestra demasiado inflexible, por 
ejemplo en Redes de Area Local (LANs, o RALs). Estas redes est\'an compuestas 
generalmente por un peque\~no n\'umero de m\'aquinas localizadas en el mismo 
edificio, o incluso en la misma planta, que est\'an interconectadas para 
proporcionar un entorno de trabajo homogeneo. Es t\'{\i}pico que se quiera 
compartir ficheros entre estos nodos, o ejecutar aplicaciones 
distribuidas en diferentes m\'aquinas.


\index{redes!intercambio de paquetes}
Estas tareas requieren una aproximaci\'on completamente diferente a las 
redes. En lugar de reenviar ficheros completos con una descripci\'on del 
trabajo, todos los datos se fragmentan en peque\~nas unidades (paquetes), 
que se env\'{\i}an inmediatamente al nodo destino, donde son reensamblados. 
Este tipo de redes son llamadas \emph{redes de intercambio de paquetes}. 
Entre otras cosas, esto permite ejecutar aplicaciones interactivas a 
trav\'es de la red. El coste de esto supone, por supuesto, una complejidad 
adicional al software.


La soluci\'on que han adoptado los sistemas \unix{}~--- y muchos 
no-\unix{}~--- es conocida como TCP/IP. En esta secci\'on echaremos un 
vistazo a sus conceptos b\'asicos.



\subsection{Introducci\'on a las Redes TCP/IP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.intro}
\index{ARPANET}

El TCP/IP tiene sus or\'{\i}genes en un proyecto de investigaci\'on fundado en 
Estados Unidos por el DARPA (Defense Advanced Research Projects Agency, 
Agencia de Proyectos Avanzados de Investigaci\'on en Defensa) en 1969. \'Esta 
fue una red experimental, la red ARPANET, que paso a ser operativa en 
1975, despu\'es de haber demostrado ser un \'exito.


\index{redes!Internet}
\index{Internet}
En 1983, fue adoptado como est\'andar el nuevo conjunto de protocolos 
TCP/IP, y todos los nodos de la red pasaron a utilizarlo. Cuando ARPANET 
por fin dio paso a Internet (con la propia ARPANET integr\'andose en su 
existencia en 1990), el uso del TCP/IP se hab\'{\i}a extendido a redes m\'as 
alla de la propia Internet. Las m\'as destacables son las redes locales 
\unix{}, pero con la llegada de los equipos telef\'onicos digitales 
r\'apidos, como la RDSI, tambi\'en tiene un futuro prometedor como transporte 
en redes telef\'onicas.


\index{Marx, Groucho}
\index{Universidad Groucho Marx}
\index{Kempen, Fred van}
Para ilustrar las explicaciones que demos en las siguientes secciones,
tomaremos como ejemplo una red t\'{\i}pica: la de una universidad,
concretamente la hipot\'etica Universidad Groucho Marx (GMU) situada, por
ejemplo, en alg\'un lugar de Libertonia. En esta universidad, la mayor\'{\i}a de los departamentos mantienen sus propias redes de \'area local,
mientras que algunos 
comparten una, y otros poseen varias. Todos ellos est\'an 
interconectados, y est\'an enganchados a Internet a trav\'es de un solo 
enlace de alta velocidad.


\index{remoto!acceso}
Supongamos una m\'aquina Linux conectada a una LAN de nodos \unix{} en el 
Departamento de Matem\'aticas, y su nombre es \host{erdos}. Para acceder a 
un nodo del Departamento de F\'{\i}sicas, por ejemplo \host{quark}, 
introducir\'a el siguiente comando:


\begin{tscreen}
\begin{verbatim}
$ rlogin quark.physics
Last login: Mon Feb  2 21:06:19 on tty1

Linux 2.0.0 #1 Sun Dec 7 19:07:05 MET 1997 (POSIX)
[...]
\end{verbatim}
\end{tscreen}


En la l\'{\i}nea de comandos, introducir\'a su nombre de acceso, pongamos que es 
\user{andres}, y su clave. Entonces dispondr\'a de una shell de \host{quark}, 
sobre la que puede escribir como si estuviera sentado en la consola del 
sistema. Tras salir de la shell volver\'a a tener la l\'{\i}nea de comandos 
de su propia m\'aquina. Acaba de utilizar una de las aplicaciones de interactividad 
instant\'anea que proporciona TCP/IP: el acceso remoto.


\index{remoto!sesi\'on X11}
Mientras est\'e conectado a \host{quark}, podr\'{\i}a tambi\'en desear ejecutar 
una aplicaci\'on X, como un programa de dibujo de funciones, o un visor de 
Postscript. Para indicar a esta aplicaci\'on que desea ver las ventanas en 
su monitor local, debe modificar la variable de entorno DISPLAY:


\begin{tscreen}
\${} export DISPLAY=erdos.maths:0.0
\end{tscreen}


Si pone en marcha ahora su aplicaci\'on, esta contactar\'a con su servidor X 
en lugar del de \host{quark}, y mostrar\'a todas las ventanas en su 
monitor. Por supuesto, esto requiere que est\'e ejecutando X11 en 
\host{erdos}. La clave est\'a en que TCP/IP permite a \host{quark} y a 
\host{erdos} enviarse paquetes X11 en ambos sentidos para darle a Ud. la 
impresi\'on de que est\'a en un \'unico sistema. La red es casi transparente 
en este caso.


Otra aplicaci\'on muy importante en redes TCP/IP es NFS, abreviatura de 
Network File System (Sistema de Ficheros de Red). Es otra forma de hacer 
trasparente la red, porque b\'asicamente permite montar jerarqu\'{\i}as de 
directorios de otras m\'aquinas, de modo que aparezcan como sistemas de 
ficheros locales. Por ejemplo, todos los directorios ``home'', o 
personales, de los usuarios pueden estar en una m\'aquina servidor central, 
desde la cual montan los directorios el resto de m\'aquinas de la LAN. El 
efecto de esto es que los usuarios pueden acceder a cualquier m\'aquina, y 
encontrarse a s\'{\i} mismos en el mismo directorio. De forma similar, es 
posible instalar aplicaciones que requieren gran cantidad de espacio en 
disco (tales como \TeX) en una \'unica m\'aquina, y exportar estos 
directorios a otras m\'aquinas. Volveremos sobre NFS en el cap\'{\i}tulo~\ref{nfs}.


Por supuesto, esto son s\'olo ejemplos de lo que se puede hacer en un entorno 
de redes TCP/IP: las posibilidades son casi ilimitadas.


Ahora echaremos una mirada m\'as de cerca al modo en que trabaja TCP/IP. 
Esto es necesario para comprender c\'omo y por qu\'e tiene que configurar su 
m\'aquina. Comenzaremos examinando el hardware, y poco a poco recorreremos 
todo el camino.


\subsection{Ethernets}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.history}
\index{protocolo!Ethernet}
\index{Ethernet|(}

El tipo de hardware m\'as utilizado en LANs es lo que comunmente conocemos como 
\emph{Ethernet}. Consta de un solo cable con los nodos colgando de \'el a 
trav\'es de conectores, clavijas o transceptores. Las ethernet simples, 
son baratas de instalar, lo que unido a un flujo de transferencia neto de 
10 Megabits por segundo avala gran parte de su popularidad.


\index{Ethernet!fino}
\index{thinnet}
\index{connector BNC}
Hay tres tipos de Ethernet, en funci\'on de su cable, llamadas \emph{gruesas}, 
\emph{finas} y \emph{de par trenzado}. Tanto el fino como el grueso utilizan 
cable coaxial, diferiendo en el grosor y el modo de conectar este cable 
a los nodos. El Ethernet fino emplea conectores ``BNC'' con forma de T, que se 
pinchan en el cable y se enganchan a los conectores de la parte trasera del 
ordenador. El Ethernet grueso requiere que realice un peque\~no agujero 
en el cable, y conecte un transceptor utilizando un ``conector vampiro''. 
Entonces se pueden conectar uno o m\'as nodos al transceptor. Los cables 
Ethernet fino y grueso pueden alcanzar una distancia de 200 y 500 metros, 
respectivamente, y es por ello que se les llama tambi\'en 10base-2 y 
10base-5. El par trenzado usa un cable hecho de dos hilos de cobre como 
las que se encuentran en las instalaciones telef\'onicas ordinarias, pero 
generalmente necesitan hardware adicional. Tambi\'en se conoce como 
10base-T.


A pesar de que a\~nadir un nodo a una Ethernet gruesa es un poco lioso, eso 
no tirar\'a abajo la red; sin embargo, para a\~nadir un nodo en una instalaci\'on de cable 
fino, se debe interrumpir el servicio de red al menos por unos minutos ya 
que se debe cortar el cable para insertar el conector.


La mayor\'{\i}a de gente prefiere el Ethernet fino porque es barato: las 
tarjetas de PC pueden encontrarse por unos 50 d\'olares americanos (unas 5000 pesetas), o incluso
menos, y el cable est\'a por unos centavos el metro. Sin embargo, para 
instalaciones de gran escala, es m\'as apropiado el Ethernet grueso. Por 
ejemplo, la Ethernet del Departamento de Matem\'aticas de la GMU utiliza Ethernet 
gruesa, de modo que no se interrumpe el tr\'afico cada vez que se a\~nade un 
nodo a la red.


Uno de los inconvenientes de la tecnolog\'{\i}a Ethernet es su limitada 
longitud de cable, que imposibilita cualquier uso fuera de las LANs. Sin 
embargo, pueden enlazarse varios segmentos de Ethernet entre s\'{\i} utilizando
repetidores, puentes o encaminadores\footnote{N. del T.: Respectivamente, {\it repeaters}, {\it bridges} y {\it routers}}.
Los repetidores simplemente copian las 
se\~nales entre dos o m\'as segmentos, de forma que todos los segmentos 
juntos act\'uan como si fuese una \'unica Ethernet. Debido a requisitos 
de tiempos, no puede haber m\'as de cuatro repetidores entre cualquier 
par de nodos de la red. Los puentes y encaminadores son m\'as sofisticados,
analizan los datos de entrada y los reenv\'{\i}an solo si el nodo receptor no 
est\'a en la Ethernet local.


\index{Ethernet!direcci\'on}
\index{direcci\'on!Ethernet}
Ethernet funciona como un sistema de bus, donde un nodo puede mandar 
paquetes (o \emph{tramas}) de hasta 1500 bytes a otro nodo de la misma 
Ethernet. Cada nodo se direcciona por una direcci\'on de seis bytes grabada 
en el firmware de su tarjeta Ethernet. Estas direcciones se especifican
generalmente como una secuencia de n\'umeros hexadecimales de dos d\'{\i}gitos 
separados por dos puntos, como en \host{aa:bb:cc:dd:ee:ff}.


\index{Ethernet!colisi\'on}
\index{colisi\'on, Ethernet}
Una trama enviada por una estaci\'on la ven todas las estaciones 
conectadas, pero s\'olo el nodo destinatario la toma y la procesa. Si dos 
estaciones intentan emitir al mismo tiempo, se produce una 
\emph{colisi\'on}, que se resuelve por parte de las dos estaciones 
abortando el env\'{\i}o, y reintentandolo al cabo de un rato.

\index{Ethernet|)}

\subsection{Otros tipos de Hardware}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.other-hardware}
\index{FDDI}

En instalaciones mayores, como la Universidad de Groucho Marx, Ethernet 
no es el \'unico tipo de red que puede utilizarse. En la Universidad de 
Groucho Marx cada LAN de un departamento est\'a enlazada a la troncal del 
campus, que es un cable de fibra \'optica funcionando en FDDI (\emph{Fiber 
Distributed Data Interface}). FDDI emplea un enfoque totalmente
diferente para transmitir datos, que b\'asicamente implica el env\'{\i}o de un 
n\'umero de \emph{testigos}, de modo que una estaci\'on s\'olo pueda enviar una 
trama si captura un testigo. La principal ventaja de FDDI es una 
velocidad de hasta 100~Mbps, y una longitud de cable m\'axima de hasta 200~km.


\index{Ensamblador/Desensamblador de Paquetes}
\index{protocolo!X.25}
\index{PAD}
\index{X.25}
Para enlaces de red de larga distancia, se utiliza frecuentemente un tipo 
distinto de equipos, que se basa en el est\'andar X.25. Muchas de 
las llamadas Redes P\'ublicas de Datos, como Tymnet en Estados Unidos, 
Datex-P en Alemania, o Iberpac en Espa\~na, ofrecen este servicio. X.25 
requiere un hardware especial, llamado Ensamblador/Desensamblador de 
Paquetes o \emph{PAD}. X.25 define un conjunto de protocolos de red de 
derecho propio, pero sin embargo se usa frecuentemente para conectar 
redes bajo TCP/IP y otros protocolos. Ya que los paquetes IP no se 
pueden convertir de forma simple en X.25 (y viceversa), \'estos deben ser
encapsulados en paquetes X.25 y enviados a trav\'es de la red.


\index{protocolo!AX.25}
\index{radioaficionado}
\index{ham radio}
\index{AX.25}
Frecuentemente, los radioaficionados usan sus propios equipos de radio para 
conectar sus ordenadores en red; esto se llama \emph{packet radio} o 
\emph{ham radio}. El protocolo utilizado por el packet radio es el 
llamado AX.25, que deriva del X.25.


Otras t\'ecnicas implican el uso de las lentas pero baratas l\'{\i}neas serie 
para acceder bajo demanda. Esto requiere aun otros protocolos para la 
transmisi\'on de paquetes, como SLIP o PPP, que se describen m\'as adelante.


\subsection{El Protocolo IP (Internet Protocol)}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.ip}
\index{protocolo!IP|see {IP}}
\index{Internet Protocol|see {IP}}
\index{IP|(}
\index{encaminamiento!datagramas IP|see {IP, encaminamiento}}

Por supuesto, Ud. no querr\'a que su red est\'e limitada a una 
Ethernet. Idealmente, Ud. desear\'{\i}a poder acceder a la red sin importarle
ni el hardware del que dispone ni el n\'umero de subestaciones. Por ejemplo, en 
instalaciones grandes como la Universidad de Groucho Marx, habr\'a 
varias Ethernets separadas, que han de conectarse de alguna manera. En 
la GMU, el departamento de matem\'aticas tiene dos Ethernets: una red de 
m\'aquinas r\'apidas para profesores y graduados, y otra con m\'aquinas m\'as lentas 
para estudiantes. Ambas redes est\'an colgadas de la red troncal FDDI del campus.


\index{reenv\'{\i}o!IP}
\index{IP!reenv\'{\i}o}
\index{IP!pasarela}
\index{pasarela}
Esta conexi\'on se gestiona con un nodo dedicado, denominado \emph{pasarela, 
o gateway}, que maneja los paquetes entrantes y salientes copi\'andolos 
entre las dos Ethernets y el cable de fibra \'optica. Por ejemplo, si se encuentra 
en el Departamento de Matem\'aticas, y quiere acceder a \host{quark} situada en la LAN
del Departamento de F\'{\i}sicas desde su m\'aquina \linux{}, el software de red no 
puede mandar paquetes a \host{quark} directamente, porque no est\'a en la 
misma Ethernet. Por tanto, tiene que confiar en la pasarela para que 
act\'ue como retransmisor. La pasarela (llam\'emosla \host{sophus}) 
reenv\'{\i}a entonces estos paquetes a su pasarela hom\'ologa \host{niels} del 
Departamento de F\'{\i}sicas, usando la troncal, y por fin \host{niels} los 
entrega a la m\'aquina destino. El flujo de datos entre \host{erdos} y 
\host{quark} se muestra en la figura~\ref{intro.fig.ip-flow} (con 
disculpas a Guy L. Steele).

\begin{figure}[htbp]
 \iftex
  \ifps
   \begin{center}
    \mbox{\epsffile{figures/ip-flow.epsf}}
   \end{center}
  \else
   \begin{center}
    \input{ip-flow.eepic}
   \end{center}
  \fi
 \else
 \fi
 \caption{
  \label{intro.fig.ip-flow}
  Los tres pasos para enviar un datagrama desde \host{erdos}
  a \host{quark}.
 }
\end{figure}


\index{IP!encaminamiento}
Este esquema de env\'{\i}o de datos al nodo remoto se llama 
\emph{encaminamiento}, y en este contexto a los paquetes se les denomina 
a menudo \emph{datagramas}. Para facilitar las cosas, el 
intercambio de datagramas est\'a gobernado por un \'unico protocolo que es 
independiente del hardware utilizado: IP, o \emph{Internet Protocol}. En 
el cap\'{\i}tulo~\ref{tcpip}, trataremos el IP y el encaminamiento en mayor 
detalle.


\index{internetworking}
\index{redes!interconexi\'on|see {internetworking}}
\index{Internet!vs. internetworking}
El principal beneficio del IP es que convierte a redes f\'{\i}sicamente 
distintas en una red aparentemente homog\'enea. A esto se le llama 
{\it internetworking} (interconexi\'on de redes), y a la resultante
``meta-red'' se la denomina \emph{internet}.
Observe aqu\'{\i} la sutil diferencia entre \emph{una} internet y \emph{La} 
Internet. El \'ultimo es el nombre oficial de una internet global particular.


\index{direcci\'on!IP}
\index{IP!direcci\'on}
\index{notaci\'on de puntos}
Claro que el IP tambi\'en necesita un esquema de direccionamiento 
independiente del hardware. Esto se consigue asignando a cada nodo un 
n\'umero \'unico de 32 bits, que define su \emph{direcci\'on~IP}. Una 
direcci\'on~IP se escribe normalmente como 4 n\'umeros en decimal, uno por cada 
divisi\'on de 8 bits, y separados por puntos. Por ejemplo, \host{quark} 
podr\'{\i}a tener una direcci\'on~IP \host{0x954C0C04}, que se escribir\'{\i}a como 
\host{149.76.12.4}. A este formato se le llama notaci\'on de puntos.


\index{direcci\'on!IP vs. nombre de nodo}
\index{direcci\'on!Ethernet vs. direcci\'on IP}
Se dar\'a cuenta de que ahora tenemos tres tipos distintos de direcciones: 
primero, tenemos el nombre del nodo, \host{quark}, despu\'es tenemos 
las direcciones~IP, y por fin est\'an las direcciones hardware, como la 
direcci\'on Ethernet de 6 bytes. De alguna forma todas ellas deben 
relacionarse, de modo que cuando escriba \prog{rlogin quark}, se le pueda 
pasar la direcci\'on~IP al software de red; y cuando el nivel IP
env\'{\i}e datos a la Ethernet del Departamento de F\'{\i}sicas, de
alg\'un modo tiene que encontrar a qu\'e direcci\'on Ethernet
corresponde la direcci\'on~IP. Lo cual no resulta trivial.


No entraremos en esto aqu\'{\i}, sino que lo dejamos para el 
cap\'{\i}tulo~\ref{tcpip}. De momento, es suficiente con indicar que estos 
pasos para encontrar las direcciones se llaman \emph{resoluci\'on de 
nombres}, para mapear nombres de nodo con direcciones~IP, y 
\emph{resoluci\'on de direcciones}, para hacer corresponder estas \'ultimas
con direcciones hardware.


\subsection{IP en L\'{\i}neas Serie, SLIP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.slip}
\index{protocolo!CSLIP}
\index{protocolo!SLIP}
\index{protocolo!PPP}
\index{tel\'efono, env\'{\i}o de datos sobre}
\index{IP en l\'{\i}nea serie|see {SLIP}}
\index{Compressed Serial Line IP|see {CSLIP}}
\index{IP en l\'{\i}neas serie|see {PPP}}
\index{Point-to-Point Protocol|see {PPP}}
\index{SLIP}
\index{CSLIP}
\index{PPP}

Para l\'{\i}neas serie se usa frecuentemente el est\'andar ``de facto'' 
conocido como SLIP o \emph{Serial Line IP} (IP sobre l\'{\i}nea serie). Una 
modificaci\'on del SLIP es el CSLIP, o \emph{SLIP Comprimido}, que realiza 
compresi\'on de las cabeceras~IP para aprovechar el bajo ancho de banda que 
proporcionan los enlaces serie.\footnote{
  SLIP est\'a descrito en la norma RFC~1055. La compresi\'on de cabeceras 
  CSLIP, basada en \'el, se describe en la RFC~1144.
} Un protocolo serie distinto es el PPP, o \emph{Point-to-Point Protocol 
(Protocolo Punto a Punto)}. PPP dispone de muchas m\'as caracter\'{\i}sticas que 
SLIP, incluyendo una fase de negociaci\'on del enlace. Su principal ventaja 
sobre SLIP es, sin embargo, que no se limita a transportar datagramas~IP, 
sino que se dise\~n\'o para permitir la transmisi\'on de cualquier tipo de 
datagramas.


\index{IP|)}

\subsection{El Protocolo de Control de Transmisi\'on, TCP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.tcp}
\index{Transmission Control Protocol|see {TCP}}
\index{protocolo!TCP}
\index{TCP|(}

Pero la historia no se acaba con el env\'{\i}o de datagramas de un 
nodo a otro. Si desea acceder a \host{quark}, necesita disponer de una conexi\'on 
fiable entre su proceso \prog{rlogin} en \host{erdos} y el proceso de 
shell en \host{quark}. Para ello, la informaci\'on enviada en uno y otro 
sentido debe dividirse en paquetes en el origen, y ser reensamblada en un 
flujo de caracteres por el receptor. Esto que parece trivial, implica 
varias tareas complejas.


Una cosa importante a saber sobre IP es que, por s\'{\i} solo, no es fiable. 
Suponga que diez personas de su Ethernet comienzan a transferirse la 
\'ultima versi\'on de XFree86 del servidor de FTP de GMU. La cantidad de 
tr\'afico generada por esto podr\'{\i}a ser excesiva para que la maneje la 
pasarela, porque es demasiado lenta, y anda escasa de memoria. Si en ese
momento Ud. env\'{\i}a un paquete a \host{quark}, \host{sophus} podr\'{\i}a 
tener agotado el espacio del buffer durante un instante y por tanto no
ser\'{\i}a 
capaz de reenviarlo. IP resuelve este problema simplemente descart\'andolo. 
El paquete se pierde irrevocablemente. Lo cual traslada la 
responsabilidad de comprobar la integridad y exactitud de los datos a 
los nodos extremos, y su retransmisi\'on en caso de error.


De esto se encarga otro protocolo, TCP, o \emph{Transmission Control 
Protocol} (Protocolo de Control de la Transmisi\'on), que construye un 
servicio fiable por encima de IP. La propiedad esencial de TCP es que usa 
IP para darle la impresi\'on de una conexi\'on simple entre los procesos en 
su equipo y la m\'aquina remota, de modo que no tiene que preocuparse de 
c\'omo y sobre qu\'e ruta viajan realmente sus datos. Una conexi\'on TCP 
funciona b\'asicamente como una tuber\'{\i}a de doble sentido en la que ambos 
procesos pueden escribir y leer; puede imaginarla como una conversaci\'on
telef\'onica.


\index{red!conexiones|see {red, puerto}}
\index{puerto|see {red, puerto}}
\index{red!puerto}
TCP identifica los extremos de tal conexi\'on por las direcciones~IP de los 
dos nodos implicados, y el n\'umero de los llamados \emph{puertos} de cada 
nodo. Los puertos se pueden ver como puntos de enganche para conexiones 
de red. Si vamos a explotar el ejemplo del tel\'efono un poco m\'as, uno 
puede comparar las direcciones~IP con los prefijos de \'area (los n\'umeros 
representar\'{\i}an ciudades), y los n\'umeros de puerto con los c\'odigos locales 
(n\'umeros que representan tel\'efonos de personas concretas).


\index{remoto!acceso}
En el ejemplo de \prog{rlogin}, la aplicaci\'on cliente (\prog{rlogin}) 
abre un puerto en \host{erdos}, y se conecta al puerto 513 de 
\host{quark}, en el que se sabe que est\'a escuchando el servidor 
\prog{rlogind}. Esto establece una conexi\'on TCP. Usando esta conexi\'on, 
\prog{rlogind} realiza el procedimiento de autorizaci\'on, y entonces 
muestra la shell. La entrada y salida est\'andar de la shell se redirigen 
a la conexi\'on TCP, de modo que cualquier cosa que escriba a \prog{rlogin} 
en su m\'aquina ser\'a pasado a trav\'es del canal TCP y entregado a la shell 
como entrada est\'andar.


\index{TCP|)}


\subsection{El Protocolo de Datagramas de Usuario, UDP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.udp}
\index{User Datagram Protocol|see {UDP}}
\index{protocolo!UDP}
\index{UDP|(}

Tambi\'en es cierto que TCP no es el \'unico protocolo de usuario en redes 
TCP/IP. Aunque adecuado para aplicaciones como \prog{rlogin}, la 
sobrecarga que impone es prohibitiva para aplicaciones como NFS. Por 
contra, \'este usa un protocolo derivado de TCP llamado UDP, o \emph{User 
Datagram Protocol} (Protocolo de Datagramas de Usuario). De igual modo que 
TCP, UDP tambi\'en permite que una aplicaci\'on contacte con un servicio en 
un puerto concreto de la m\'aquina remota, pero no establece una conexi\'on 
para ello. En cambio, puede usarlo para enviar paquetes sueltos al 
servicio destino~-- de ah\'{\i} su nombre.


Suponga que ha montado la jerarqu\'{\i}a del directorio \TeX{} del servidor de 
NFS central del departamento, \file{galois}, y desea ver un documento que 
describe como usar \LaTeX{}. Arranca su editor, y lee el fichero 
completo. Sin embargo, le llevar\'{\i}a demasiado tiempo establecer una 
conexi\'on TCP con \file{galois}, enviar el fichero, y liberarla de nuevo. 
En cambio, se hace una petici\'on a \file{galois}, que env\'{\i}a el fichero en 
un par de paquetes UDP, que es mucho m\'as r\'apido. Sin embargo, UDP no se 
hizo para controlar la p\'erdida o corrupci\'on de paquetes. Es 
responsabilidad de la aplicaci\'on~~-- en este caso NFS~-- tener en cuenta 
esto.


\index{UDP|)}

\subsection{M\'as sobre Puertos}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.ports}
\index{red!servicios|see {puerto}}
\index{servicios}
\index{red!puerto|(}

Los puertos se pueden ver como puntos de anclaje para conexiones de red. 
Si una aplicaci\'on quiere ofrecer un cierto servicio, se engancha a un 
puerto y espera a los clientes (a esto tambi\'en se le llama 
\emph{escuchar} en un puerto). Un cliente que quiera usar este servicio 
consigue un puerto libre en su nodo local, y se conecta al puerto del 
servidor en el nodo remoto.


\index{puerto!n\'umeros}
\index{red!n\'umeros de puerto}
Una propiedad importante de los puertos es que una vez que se ha 
establecido una conexi\'on entre el cliente y el servidor, otra copia del 
servidor puede engancharse al puerto servidor y esperar a m\'as clientes. 
Esto permite, por ejemplo, varios accesos remotos simult\'aneos al mismo 
nodo, usando todos ellos el mismo puerto 513. TCP es capaz de distinguir 
unas conexiones de otras, ya que todas ellas provienen de diferentes 
puertos o nodos. Por ejemplo, si accede dos veces a \host{quark} desde 
\host{erdos}, entonces el primer cliente \prog{rlogin} usar\'a el puerto 
local 1023, y el segundo usar\'a el puerto n\'umero 1022; sin embargo, ambos se 
conectar\'an al mismo puerto 513 de \host{quark}.


\index{servicios!reconocidos}
\index{servicios!y n\'umeros de puerto}
Este ejemplo muestra el uso de puertos como puntos de encuentro, donde un 
cliente contacta con un puerto espec\'{\i}fico para obtener un servicio 
espec\'{\i}fico. Para que un cliente sepa el n\'umero de puerto adecuado, se ha 
tenido que llegar a un acuerdo entre los administradores de los dos 
sistemas para asignar estos n\'umeros. Para servicios ampliamente usados, 
como \prog{rlogin}, estos numeros tienen que administrarse centralmente. 
Esto lo realiza el IETF (o \emph{Internet Engineering Task Force}), que 
regularmente publica un RFC (Request For Comment) denominado \emph{Assigned
Numbers} (N\'umeros Asignados). Describe, entre otras cosas, los n\'umeros de 
puerto asignados a \emph{servicios reconocidos}. \linux{} utiliza un fichero 
que mapea nombres con n\'umeros, llamado \file{/etc/services}. Se describe 
en la secci\'on~\ref{appl.services}.


Merece la pena indicar que aunque las conexiones TCP y UDP se
basan en puertos, estos n\'umeros no entran en conflicto. Esto significa
que el puerto TCP 513, por ejemplo, es diferente del puerto UDP 513. De
hecho, estos puertos sirven como puntos de acceso para dos servicios
diferentes, como \keyword{rlogin} (TCP) y \keyword{rwho} (UDP).


\index{red!puerto|)}

\subsection{La Librer\'{\i}a de Sockets}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.sockets}
\index{red!interface de programaci\'on}
\index{librer\'{\i}a de sockets BSD}
\index{socket}

En sistemas operativos \unix{}, el software que realiza todas las tareas
y protocolos descritos anteriormente es generalmente parte del kernel, y por
tanto tambi\'en del de \linux. El interface de programaci\'on m\'as com\'un en el mundo
\unix{} es la Librer\'{\i}a de Socket de Berkeley, \emph{Berkeley Socket Library}.
Su nombre proviene de una analog\'{\i}a popular que ve los puertos como 
enchufes, y
conectarse a un puerto como enchufarse. Proporciona la llamada
\func{bind(2)} para especificar un nodo remoto, un protocolo de
transporte, y un servicio al que un programa pueda conectarse o escuchar
(usando \func{connect(2)}, \func{listen(2)}, y \func{accept(2)}). La
librer\'{\i}a
de sockets, sin embargo, es algo m\'as general, ya que proporciona no solo una
clase de sockets basados en TCP/IP (los sockets \func{AF\_INET}), sino
tambi\'en una clase que maneja conexiones locales a la m\'aquina (la clase
\func{AF\_UNIX}). Algunas implementaciones pueden manejar tambi\'en otras
clases, como el protocolo XNS ((\emph{Xerox Networking System}), o X.25.


En \linux{}, la librer\'{\i}a de sockets es parte de la librer\'{\i}a C est\'andar
\file{libc}. Actualmente s\'olo soporta los sockets \func{AF\_INET} y
\func{AF\_UNIX}, pero se hacen esfuerzos para incorporar el soporte de los
protocolos de red de Novell, de modo que se a\~nadir\'{\i}an eventualmente una o m\'as
clases de sockets.

\index{TCP/IP|)}


% \subsection{Internetworking}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \label{intro.tcpip.internetworking}
% In section~\ref{intro.tcpip.ip} we stated that it was IP's duty
% to link physically dissimilar networks to form an internet. But,
% of course, it would be rather limiting if this were the only way
% to link two networks. For example, assume a LAN that consists
% of several Ethernets. Linking them by just inserting a long piece
% of cable between the segments does not work because of the electrical
% specifications. On the other hand, inserting a gateway at each
% junction is prohibitive because of the delay introduced. Imagine
% some data of yours had to pass a dozen or so gateways just to
% travel a few hundred yards distance, being constantly wrapped and
% unwrapped by Ethernet drivers!
%
%
% A simple solution to this problem is the use of \emph{repeaters}.
% These are electrical devices used to connect two Ethernets, who
% do not perform any analysis of data passing through it, but only
% copy bits between them. Now traffic may float freely between these
% Ethernets. For example, at GMU's Mathematics Department, repeaters
% would be the device of choice if the professors' Ethernet had to be
% enlarged in order to give each professor his or her own X-terminal.
%
%
% Sadly, this does not work in all cases. For one, timing specifications
% require that a signal sent by one station on an Ethernet reaches
% any other station within a certain amount of time. This puts an upper
% boundary of four on the number of repeaters two stations may be apart.
%
%
% Another drawback of repeaters is that instead of at most a few dozen
% machines on one local segment, all machines from the linked segments
% compete for the right to transmit a frame. When segments A and B are
% linked by a repeater, all stations on segment A have to shut up when
% a station on segment B talks.
%
%
% Another solution is the use of \emph{bridges}. These are still
% Ethernet-specific devices, but instead of simple bit-shuffling,
% a bridge receives entire frames, analyzes the recipient's address, and
% only copies it to one of the adjacent segments when the recipient is known
% to be on that segment (or known to be reachable through this segment).
% A bridge does not suffer from the limitations of a repeater, because
% the single Ethernets remain separate entities, and frames are only copied
% to another segment if really needed. The drawback of bridges is that they
% need to be configured properly.
%
%
% As an example, a bridge might be useful to link the students' and
% professors' Ethernets at the Mathematics Department.
%
%
% Now, we have seen three types of equipment to link different
% physical networks: repeaters, bridges, and gateways (or routers),
% each at a different ``level'' of networking.
% Of course, one can also think of internetworking schemes that operate
% at still higher levels. For example, one could think of a program
% that accepts TCP connections for remote hosts, multiplexes
% them onto a serial line, with a similar program demultiplexing the whole
% on another machine and opening a separate TCP connection to the
% target host.\footnote{
%  In fact, there is a program for \linux{} that does roughly this.
%  This is the \prog{term(1)} program written by Michael O'Reilly,
%  \email{oreillym@tartarus.uwa.edu.au}.
% }
%

\section{Redes con \linux{}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Net-1}
\index{Net-2d}
\index{Net-2Debugged}
\index{Biro, Ross}
\index{Cox, Alan}
\index{Kempen, Fred van}

Siendo el resultado del esfuerzo concentrado de programadores de todo el
mundo, \linux{} no habr\'{\i}a sido posible sin la red global. As\'{\i} que no
sorprende que ya en los primeros pasos del desarrollo, varias personas
comenzaran a trabajar para dotarlo de capacidades de red. Casi desde el
principio exist\'{\i}a ya una implementaci\'on de UUCP para \linux{}; y fue
en el oto\~no de 1992 cuando se comenz\'o a desarrollar el soporte de TCP/IP, 
cuando Ross Biro y otros crearon lo que ahora se conoce como Net-1.


Despu\'es de que Ross dejara el desarrollo activo en Mayo de 1993, Fred
van~Kempen comenz\'o a trabajar en una nueva implementaci\'on, reescribiendo
gran parte del c\'odigo. Este esfuerzo continuado se conoce como Net-2.
En el verano de 1992 sali\'o la primera versi\'on p\'ublica de Net-2d (como
parte del kernel 0.99.10), y ha sido mantenida y ampliada por varias
personas, muy especialmente por Alan Cox, dando lugar al Net-2Debugged. Tras una
dura correcci\'on y numerosas mejoras en el c\'odigo, cambi\'o su nombre a
Net-3 despu\'es de que saliese \linux{} 1.0. Esta es la versi\'on del c\'odigo
de red que se incluye actualmente en las versiones oficiales del kernel.


Net-3 ofrece controladores de dispositivo para una amplia variedad de tarjetas
Ethernet, as\'{\i} como SLIP (para enviar tr\'afico de red sobre l\'{\i}neas serie),
y PLIP (para l\'{\i}neas paralelo). Con Net-3, \linux{} tiene una
implementaci\'on de TCP/IP que se comporta muy bien en entornos de red de
\'area local, mostrandose superior a algunos de los Unix comerciales para PCs.
El desarrollo se mueve actualmente hacia la estabilidad necesaria para
su funcionamiento fiable en nodos de Internet.


Adem\'as de estas facilidades, hay varios proyectos en marcha que mejorar\'an
la versatilidad de \linux. Un controlador para PPP (el protocolo punto a
punto, otra forma de enviar tr\'afico de red sobre l\'{\i}neas serie) est\'a en
estado Beta actualmente, y otro controlador AX.25 para {\it ham radio} est\'a
en estado Alfa. Alan Cox tambi\'en ha implementado un controlador
para el protocolo
IPX de Novell, pero el esfuerzo para un paquete de red completo
compatible con el de Novell se ha paralizado por el momento, debido a la
negativa de Novell a facilitar la documentaci\'on necesaria. Otro
proyecto muy prometedor es \prog{samba}, un servidor de NetBIOS gratis
para Unix, escrito por Andrew Tridgell.\footnote{
 NetBIOS es el protocolo en el que se basan las aplicaciones como
 \prog{lanmanager} y Windows para Trabajo en Grupo.
}


\subsection{Diferentes Etapas de Desarrollo}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{interface del controlador de dispositivo|see {DDI}}
\index{Net-2e}
\index{Net-3}
\index{DDI}

Mientras tanto, Fred sigui\'o desarrollando, continuando con el Net-2e, que
dispone de un dise\~no m\'as revisado de la capa de red. En el momento de
escribir esto, Net-2e es aun software Beta. Lo m\'as notable sobre Net-2e
es la incorporaci\'on del DDI, el \emph{Device Driver Interface} (Interface
del controlador de dispositivo). DDI ofrece un acceso y un m\'etodo de
configuraci\'on uniforme a todos los dispositivos y protocolos de red.


\index{Urlichs, Matthias}
Otra implementaci\'on m\'as de red TCP/IP es la realizada por Matthias Urlichs, quien
escribi\'o un controlador de RDSI para \linux{} y FreeBSD. Para ello, integr\'o
algo del c\'odigo de red de BSD en el kernel de \linux{}.


En un futuro previsible, sin embargo, Net-3 parece que llegar\'a para
quedarse. Alan trabaja actualmente en una implementaci\'on del protocolo
AX.25 usado por radioaficionados. Sin duda, la {\it modularizaci\'on}, aun
por desarrollar para el kernel, traer\'a tambi\'en nuevos impulsos al c\'odigo
de red. Los m\'odulos le permiten a\~nadir controladores al kernel en tiempo de
ejecuci\'on.


Aunque todas estas diferentes implementaciones de red intentan dar el
mismo servicio, hay grandes diferencias entre ellas a nivel de kernel y
dispositivos. Adem\'as, no podr\'a configurar un sistema con un kernel Net-2e
con utilidades de Net-2d o Net-3, y viceversa. Esto s\'olo se aplica a
comandos que tienen mucho que ver con el funcionamiento interno del
kernel; las aplicaciones y los comandos de red comunes como \prog{rlogin} o
\prog{telnet} se ejecutan en cualquiera de ellos.


A pesar de todo, todas estas diferentes versiones de red no deben
preocuparle. A no ser que est\'e participando en el desarrollo activo, no
tendr\'a que preocuparse de qu\'e versi\'on del c\'odigo TCP/IP est\'a utilizando. Las
versiones oficiales del kernel siempre estar\'an acompa\~nadas de un conjunto de
herramientas de red que son compatibles con el c\'odigo de red presente en
el propio kernel.


\subsection{Donde Conseguir el C\'odigo}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{obteniendo el c\'odigo fuente}
\index{FTP, localizaci\'on del c\'odigo de \linux{}}
\index{Net-2e}
\index{Net-3}
\index{Net-BSD}

La \'ultima versi\'on del c\'odigo de red \linux{} se puede obtener mediante
FTP an\'onimo de varios sitios. El servidor oficial del Net-3 es
\host{sunacm.swan.ac.uk}, copiado en \host{sunsite.unc.edu} en el
directorio \file{system/Network/sunacm}. El \'ultimo parche para el Net-2e
y los binarios se encuentran disponibles en \host{ftp.aris.com}. El
c\'odigo de red basado en BSD de Matthias Urlichs se puede conseguir en
\host{ftp.ira.uka.de}, directorio \file{/pub/system/linux/netbsd}.

Se pueden encontrar los \'ultimos kernels en \host{nic.funet.fi}, en el
directorio \file{/pub/OS/Linux/PEOPLE/Linus}; Los nodos \host{sunsite} y
\host{tsx-11.mit.edu} tienen copias de este directorio.


\section{Mantenimiento del Sistema}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{mantenimiento, sistema}
\index{mantenimiento del sistema}

En este libro, vamos a tratar principalmente los temas de
instalaci\'on y configuraci\'on. Sin embargo la administraci\'on es mucho m\'as
importante~---  despu\'es de instalar un servicio, tambi\'en hay que
mantenerlo funcionando. Para la mayor\'{\i}a de ellos, s\'olo se necesitar\'a una
peque\~na atenci\'on, mientras que algunos, como el correo y las news,
requieren realizar tareas rutinarias para mantener actualizado el
sistema. Discutiremos estas tareas en los cap\'{\i}tulos finales.


La tarea m\'{\i}nima de mantenimiento es comprobar regularmente el
sistema y los 
ficheros de registro de cada aplicaci\'on buscando condiciones de 
error y eventos inusuales. Por lo general, es posible hacer esto escribiendo 
un par de scripts de shell y ejecut\'andolos
peri\'odicamente mediante el comando \prog{cron}. La distribuci\'on
fuente de algunas aplicaciones importantes como \prog{smail} o C News,
ya contiene esos scripts. S\'olo tendr\'a que retocarlos para
adecuarlos a sus necesidades y preferencias.


La salida de cualquiera de sus trabajos del \prog{cron} se deber\'{\i}a enviar 
a una cuenta de administraci\'on. Por defecto, muchas aplicaciones enviar\'an 
informes, estad\'{\i}sticas de uso, o res\'umenes del fichero de registro a la 
cuenta de \user{root}. Esto s\'olo tiene sentido si accede como \user{root} 
frecuentemente; una idea mucho mejor es redirigir el correo del 
\user{root} a su cuenta personal estableciendo un alias de correo como se 
describe en el cap\'{\i}tulo~\ref{smail}.


Por muy cuidadoso que sea configurando su m\'aquina, la ley de Murphy 
garantiza que \emph{surgir\'a} alg\'un problema en cualquier momento. Por lo 
tanto, el mantenimiento de un sistema implica tambi\'en estar disponible 
para quejas. Generalmente la gente espera que se pueda contactar con 
el administrador del sistema al menos por correo electr\'onico (como 
\email{root}), pero tambi\'en hay otras direcciones que se usan con frecuencia
para informar a la persona responsable de un aspecto concreto del 
mantenimiento. Por ejemplo, las quejas sobre una configuraci\'on de correo 
que funciona mal se dirigir\'an generalmente al \email{postmaster} 
(encargado del correo); y los problemas con el sistema de noticias pueden 
ser comunicados a \email{newsmaster} o \email{usenet}. El correo a 
\email{hostmaster} se deber\'{\i}a redirigir a la persona encargada de los 
servicios b\'asicos de red del nodo, y del servicio de nombres DNS si est\'a 
corriendo un servidor de nombres.


\subsection{Seguridad del Sistema}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{seguridad del sistema}
\index{seguridad!sistema}

Otro aspecto muy importante de la administraci\'on de sistemas en un 
entorno de red es proteger al sistema y a sus usuarios de intrusos. Los 
sistemas administrados sin ning\'un cuidado ofrecen muchos huecos a los malintencionados:
los ataques van desde averiguar las claves hasta acceder a nivel de Ethernet, 
y el da\~no causado puede ser desde mensajes de correo falsos hasta 
p\'erdida de datos o violaci\'on de la privacidad de los usuarios. 
Mencionaremos algunos problemas concretos cuando discutamos el contexto 
en el que pueden ocurrir, y algunas defensas comunes contra ellos.


Esta secci\'on comentar\'a algunos ejemplos y t\'ecnicas b\'asicas para pelearse 
con la seguridad del sistema. Por supuesto, los temas relatados no pueden 
tratar exhaustivamente todos los aspectos de seguridad con los que uno se puede encontrar;
sirven meramente para ilustrar los problemas que pueden 
surgir. Por tanto, la lectura de un buen libro sobre seguridad es 
absolutamente obligada, especialmente en un sistema en red. ``Practical 
UNIX Security'' de Simon Garfinkel (vease \cite{security}) es una de las
lecturas recomendadas.


La seguridad del sistema comienza con una buena administraci\'on del mismo. 
Esto incluye comprobar la propiedad y permisos de todos los ficheros y 
directorios vitales, monitorizar el uso de cuentas privilegiadas, etc. El 
programa COPS, por ejemplo, comprobar\'a su sistema de ficheros y ficheros 
de configuraci\'on comunes en busca de permisos inusuales u otras 
anomal\'{\i}as. Tambi\'en es conveniente usar un sistema de claves que fuerce 
ciertas reglas en las claves de los usuarios que las hagan dif\'{\i}ciles de 
adivinar. El sistema de claves ocultas (shadow password), por ejemplo, 
requiere que una clave tenga al menos cinco letras, y contienen tanto 
may\'usculas como min\'usculas y n\'umeros.


\index{servicios!restringir el acceso}
Cuando un servicio se hace accesible a la red, aseg\'urese de darle el 
``menor privilegio'', lo que quiere decir que no se permita hacer cosas 
que no son imprescindibles para que trabaje como se dise\~n\'o. Por ejemplo, 
deber\'{\i}a hacer sus programas con setuid \user{root} o alguna otra cuenta 
privilegiada s\'olo si realmente lo necesitan. Tambi\'en, si quiere usar un 
servicio s\'olo para una aplicaci\'on muy limitada, no dude en configuarla 
tan restrictivamente como su aplicaci\'on especial lo permita. Por ejemplo, 
si quiere permitir a m\'aquinas sin disco arrancar desde su m\'aquina, debe 
facilitar el TFTP (Trivial File Transfer Service) de modo que pueda 
obtener los ficheros de configuraci\'on b\'asicos del directorio 
\file{/boot}. Sin embargo, cuando se usa sin restringir, TFTP permite a 
cualquier usuario de cualquier lugar del mundo leer cualquier fichero 
de su sistema. Si esto no es lo que desea, ?`por qu\'e no 
restringir el servicio TFTP al directorio \file{/boot}?\footnote{
 Volveremos sobre esto en el cap\'{\i}tulo~\ref{appl}. 
}


\index{acceso!restringir}
Pensando en la misma l\'{\i}nea, podr\'{\i}a restringir ciertos servicios a 
usuarios que acceden desde ciertos nodos, digamos que s\'olo para su red local. En el 
cap\'{\i}tulo~\ref{appl}, presentaremos \prog{tcpd}, que hace esto para una 
variedad de aplicaciones de red.


Otro punto importante es evitar software ``peligroso''. Claro que 
cualquier software que utilice puede ser peligroso, porque el software puede 
tener fallos que algunos listos pueden explotar para acceder a su 
sistema. Cosas como \'esta ocurren, y no hay protecci\'on segura contra ello. 
Este problema afecta al software libre y a productos comerciales por igual.
\footnote{
 Ha habido sistemas \unix{} comerciales, por los que hay que pagar un mont\'on de 
 dinero, que ven\'{\i}an con un script de shell con setuid-\user{root} que 
 permit\'{\i}a a los usuarios obtener privilegios de \user{root} utilizando
 un conocido truco.
} Sin embargo, programas que requieren privilegio especial son 
inherentemente m\'as peligrosos que otros, ya que un agujero de estos puede 
tener consecuencias dr\'asticas.\footnote{
 En 1988, el gusano RTM llevo a gran parte de Internet a un colapso, en 
 parte por explotar un agujero que hab\'{\i}a en algunos programas 
 \prog{sendmail}.
 Este agujero ya ha sido reparado con creces.
} Si instala un programa setuid con prop\'ositos de red, sea doblemente 
cuidadoso y no deje de leerse toda la documentaci\'on, de modo que no 
cree una brecha en la seguridad por accidente.


\index{tripwire@\prog{tripwire}}
Nunca olvide que sus precauciones pueden fallar, por muy cuidadoso que 
haya sido. Por eso deber\'{\i}a asegurarse de que detecta pronto
a los intrusos.
Comprobar los ficheros de actividad es un buen comienzo, pero el intruso 
probablemente sea bastante listo, y borrar\'a cualquier huella que haya 
dejado. Sin embargo, hay herramientas como \prog{tripwire}\footnote{
  Escrita por Gene Kim y Gene Spafford.
} que permite comprobar ficheros vitales del sistema para ver si sus 
contenidos o permisos han cambiado. \prog{tripwire} realiza varios 
checksums\footnote{N. del T.: Sumas de bytes con objeto de comprobar 
alguna modificaci\'on no ``autorizada'' en el fichero.} 
fuertes sobre estos ficheros y los almacena en una base de 
datos. En las siguientes ejecuciones, se reeval\'uan y comparan los 
checksums con los almacenados para detectar cualquier modificaci\'on.



\section{Vistazo a los Siguientes Cap\'{\i}tulos}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.outlook}

Los siguientes cap\'{\i}tulos tendr\'an que ver con configurar \linux{} para 
redes TCP/IP, y con la ejecuci\'on de algunas aplicaciones importantes. 
Antes de que se manche las manos con la edici\'on de ficheros y similares, 
examinaremos IP algo m\'as de cerca en el cap\'{\i}tulo~\ref{tcpip}. Si ya sabe 
como funciona el encaminamiento~IP, y c\'omo se realiza la resoluci\'on de 
direcciones, quiz\'a desee saltarse este cap\'{\i}tulo.


El cap\'{\i}tulo~\ref{hardware} trata los aspectos m\'as b\'asicos de 
configuraci\'on, como construir un kernel y configurar su tarjeta Ethernet. 
La configuraci\'on de los puertos serie se relata en un cap\'{\i}tulo aparte, ya 
que la discusi\'on no se aplica s\'olo a redes TCP/IP, sino que tambi\'en es 
relevante para UUCP.


El cap\'{\i}tulo~\ref{iface} le ayudar\'a a configurar su m\'aquina para redes 
TCP/IP. Contiene pasos de instalaci\'on para nodos aislados (solamente con 
enlace local), y nodos conectados a una Ethernet. Tambi\'en le presentar\'a unas 
pocas herramientas \'utiles que puede utilizar para comprobar y retocar su 
configuraci\'on. El siguiente cap\'{\i}tulo expone c\'omo configurar la resoluci\'on 
de nombres, y explica c\'omo montar un servidor de nombres.


Esto va seguido de dos cap\'{\i}tulos que tratan de la configuraci\'on y uso de SLIP 
y PPP, respectivamente. El cap\'{\i}tulo \ref{slip} explica c\'omo establecer 
conexiones SLIP, y da una referencia detallada de \prog{dip}, una 
herramienta que le permite automatizar la mayor\'{\i}a de pasos necesarios. El 
cap\'{\i}tulo~\ref{ppp} cubre PPP y \prog{pppd}, el demonio que se necesita 
para ello.


El cap\'{\i}tulo \ref{appl} da una corta introducci\'on a la instalaci\'on de las 
aplicaciones de red m\'as importantes, como \prog{rlogin}, \prog{rcp}, etc. 
Esto tambi\'en abarca la gesti\'on de los servicios por el \prog{inetd}, 
y c\'omo puede restringir ciertos servicios de seguridad relevante a un 
grupo de nodos de confianza.


Los dos cap\'{\i}tulos siguientes hablan de NIS, el sistema de informaci\'on de 
red (Network Information System), y NFS, el sistema de ficheros de red 
(Network File System). NIS es una herramienta \'util para distribuir 
informaci\'on de administraci\'on, como las claves de usuario, en red de \'area 
local. NFS le permite compartir sistemas de ficheros entre varios nodos 
de su red.


El cap\'{\i}tulo \ref{uucp} le dar\'a una amplia introducci\'on a la 
administraci\'on del UUCP de Taylor, una implementaci\'on gratis del paquete 
UUCP.


El resto del libro ser\'a un viaje guiado por temas como el correo electr\'onico y 
las Noticias de Usenet. El cap\'{\i}tulo~\ref{mail} le conduce a los conceptos 
centrales del correo electr\'onico, como qu\'e aspecto tiene una direcci\'on de 
correo, y c\'omo se las arregla el sistema de manejo de correo para llevar 
su mensaje hasta el destinatario.


Los cap\'{\i}tulos~\ref{smail} y~\ref{sendmail} cubren respectivamente la puesta en 
marcha de \prog{smail} y \prog{sendmail}, dos agentes de transporte de 
correo que puede utilizar en \linux. Este libro explica ambos, ya que 
\prog{smail} es m\'as f\'acil de instalar para un principiante, mientras que 
\prog{sendmail} es m\'as flexible.


Los cap\'{\i}tulos~\ref{news} y~\ref{cnews} explican la forma en que se 
manejan las noticias en Usenet, y c\'omo instalar y usar C News, un paquete 
de software popular para la gesti\'on de las noticias de Usenet. El 
cap\'{\i}tulo~\ref{nntp} trata brevemente de c\'omo instalar un demonio NNTP 
para ofrecer el acceso a lectura de noticias para su red local. El 
cap\'{\i}tulo~\ref{newsreaders} muestra finalmente c\'omo configurar y mantener 
varios lectores de noticias.




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%                                                             %%
%%              E N D   O F   C H A P T E R                    %%
%%                                                             %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

