Antes de comenzar a montar una estructura de IP, necesitamos uno o más números de red oficiales. Una dirección IP tiene un aspecto como el siguiente: 128.6.4.3. Esta dirección sólo podrá ser usada por un ordenador de la Universidad de Marx. La primera parte de dicha dirección, 128.6, es un número de red asignado a dicha Universidad por una autoridad central. Por tanto, antes de asignar direcciones a nuestros ordenadores, deberemos obtener una dirección oficial de red. Sin embargo, alguna gente configura sus redes usando, o bien una dirección aleatoria o usando una dirección genérica suministrada por defecto en el equipo. Esta forma de trabajar podría funcionar en pequeñas redes, pero seguramente no lo hará en una mayor. Además, es posible que quisiéramos conectar nuestra red con la red de otra organización. Incluso si nuestra organización tuviese un gran control de seguridad, es posible que tuviéramos un ordenador dedicado a la investigación que estuviese conectado a una universidad u otra organización investigadora. Esta universidad o entidad estaría seguramente conectada a una red de nivel nacional. Tan pronto como uno de nuestros datagramas salga de nuestra red local va a provocar un estado de confusión en la organización con la que nos comuniquemos, porque la dirección que aparece en nuestros datagramas está probablemente asignada oficialmente a alguien distinto.
La solución es simple: obtener una dirección propia desde el principio. Además, no cuesta nada.
La decisión más importante que tenemos que hacer para configurar una red es, sin lugar a dudas, cómo asignar las direcciones IP a los ordenadores. Esta elección debe de hacerse desde el punto de vista de cómo nuestra red puede crecer. Si no se hiciese así, es casi seguro que tendremos que cambiar las direcciones en un futuro. Y cuando tengamos varios cientos de ordenadores, cambiar tantas direcciones es casi imposible.
Las direcciones son muy importantes porque los datagramas IP son enrutados
en base a dicha dirección. Por ejemplo, las direcciones de la Universidad
Rutgers tienen una estructura de dos niveles. Una dirección típica
puede ser 128.6.4.3. La dirección 128.6 es la asignada a dicha Universidad.
Visto desde el exterior, 128.6 es una simple red. Cualquier datagrama
enviado desde el exterior, que comience por 128.6, se dirigirá al
gateway
más cercano de la Universidad Rutgers. Sin embargo, dentro
de Rutgers dividimos el espacio de direcciones en "subredes". Usamos
los siguientes 8 bits de dirección para indicar a qué subred pertenece el
ordenador. Así, 128.6.4.3 pertenece a la subred 128.6.4. Generalmente, las
subredes se corresponden con redes "físicas" o reales, por ejemplo una red
Ethernet; sin embargo, veremos algunas excepciones más adelante. Los
sistemas dentro de Rutgers, a diferencia de los de fuera, contienen
información sobre la estructura de subredes de Rutgers. Así, una vez
que un datagrama para 128.6.4.3 llega a Rutgers, la red de Rutgers
lo enrutará hacia la Ethernet, Token Ring o cualquier otro tipo de red del
departamento que tiene asignado la subred 128.6.4.
Cuando queremos configurar una red, hay varias decisiones de direccionamiento que debemos afrontar:
No es absolutamente necesario usar subredes. Hay mecanismos que permiten actuar a un campus o compañía completa como una simple y gran Ethernet, así que no es necesario un enrutamiento interno. Si usamos estas tecnologías, entonces no necesitaremos dividir nuestro espacio de direcciones. En este caso, la única decisión que tenemos que tomar es la de qué clase de dirección debemos de usar. Sin embargo, recomendamos usar un enfoque de subredes o cualquier otro método de subdividir nuestro espacio de dirección en varias redes:
gateways
internos son
recomendables para todas las redes, más allá de su simplicidad.gateways
en estos momentos, podemos
descubrir que tarde o temprano necesitaremos usarlos. De esta manera,
probablemente tiene sentido asignar direcciones como si cada Ethernet o
Token Ring fuera una subred separada. Esto permitirá hacer conversiones
a subredes reales, si esto es necesario.Supongamos que estamos convencidos de que es una buena idea imponer alguna estructura en nuestras direcciones. La siguiente cuestión es cuál es la más adecuada. Hay dos enfoques básicos: subredes y múltiples números de red.
Los estándares de Internet especifican el formato de las direcciones. Para
las direcciones que comienzan entre 128 y 191 (las más usadas actualmente),
los dos primeros octetos forman el número de red; por ejemplo, en
140.3.50.1, 140.3 es el número de red. Los números de red están asignados a
una organización particular. ¿Qué hacemos con los dos siguientes octetos que
le siguen?. Podríamos optar por hacer al siguiente octeto un número de
subred, u otro esquema completamente distinto. Los gateways
dentro de
nuestra organización deben configurarse para conocer qué esquema de división
de redes estamos usando. Sin embargo, fuera de la organización nadie sabrá
si 140.3.50 es una subred y 140.3.51 es otra; simplemente, fuera se sabe que
140.3 es una organización. Desafortunadamente, esta habilidad de añadir una
estructura adicional a las direcciones, mediante el uso de subredes, no
estaba presente en las especificaciones originales y, por tanto, un
software
antiguo sería incapaz de trabajar con subredes. Si una parte
importante del software
que hemos de usar tiene este problema, entonces
no podremos dividir nuestra red en subredes.
Algunas organizaciones usan un enfoque distinto. Es posible que una
organización use varios números de red. En lugar de dividir un simple número
de red, por ejemplo 140.3, en varias subredes, como de 140.3.1 a 140.3.10,
podríamos usar 10 números distintos de red. De esta manera haríamos una
asignación desde 140.3 hasta 140.12. Todo el software
IP sabrá que
estas direcciones se corresponden con redes distintas.
A pesar de que usando números de red distintos todo funciona correctamente dentro de la organización, hay dos serias desventajas. La primera, y menos importante, es que se malgasta un gran espacio de direcciones. Hay solamente sobre unas 16.000 posibles direcciones de clase B. No queremos malgastar diez de ellas en nuestra organización, a no ser que sea bastante grande. Esta objección es menos seria, porque podríamos pedir una dirección C para este propósito y hay sobre 2 millones de direcciones C.
El problema más serio para usar varias direcciones de red, en lugar de
subredes, es que sobrecarga las tablas de enrutamiento en el resto de
Internet. Como comentamos anteriormente, cuando dividimos nuestro número de
red en subredes, esta división sólo es conocida dentro de la organización,
pero no fuera. Los sistemas externos a la organización sólo necesitan una
entrada en sus tablas para ser capaces de llegar. Por tanto, otras
Universidades tienen entradas en sus tablas de enrutamiento para 128.6,
similar al número de la red de Rutgers. Si usa un rango de redes en
lugar de subredes, dicha división será visible en todo Internet. Si usamos
los números 128.6 a 128.16, en lugar de 128.6, las otras universidades
necesitarían tener una entrada para cada uno de estos números de red en sus
tablas de enrutamiento. La mayoría de los expertos de TCP/IP recomiendan el
uso de subredes, en lugar de múltiples redes. La única razón para considerar
múltiples redes es el uso de un software
que no puede manejar subredes.
Esto era un problema hace algunos años, pero actualmente es poco frecuente.
Una última indicación sobre subredes: Las subredes deben ser "adyacentes".
Esto significa que no podemos conectar la subred 128.6.4 con la subred
128.6.5 mediante otra red, como la 128.121. Por ejemplo, Rutgers tiene
campus en Simon City y Garfunken City. Es perfectamente posible conectar
redes en ciudades distintas que sean subred de 128.6. Sin embargo, en este
caso, las líneas entre Simon City y Garfunken City deben ser parte de 128.6.
Supongamos que decidimos usar una red regional como la RegionaLnet para
comunicarnos entre dos campus, en lugar de usar su propia línea. Puesto que
RegionaLnet tiene de número de red 128.121, los gateways
y líneas de
serie que usarían empezarían por 128.121. Esto viola las reglas. No está
permitido tener gateways
o líneas que son parte de 128.121 conectando
dos partes de 128.6. Así, si queremos usar RegionaLnet entre nuestros dos
campus, tendríamos que obtener diferentes números de red para los dos
campus. (Esta regla es un resultado de las limitaciones de la tecnología de
enrutamiento. Eventualmente podría desarrollarse un software
para un
gateway
para manejar configuraciones cuyas redes no son contiguas).
Ahora, una vez decidido si vamos a usar subredes o múltiples números de red, tenemos que asignarlos. Normalmente es bastante fácil. Cada red física, ya sea Ethernet o Token Ring, ..., se le asigna un número distinto de subred. Sin embargo, existen otras opciones.
En algunos casos, puede que tenga sentido asignar varios números de subred a
una única red física. En Rutgers hay una única Ethernet que ocupa tres
edificios, usando repetidores. Está claro que a medida que vayamos añadiendo
ordenadores a esta Ethernet se irá dividiendo en varias Ethernets separadas.
Para evitar tener que cambiar de direcciones cuando esto suceda, hemos
asignado tres números de red distintas a esta Ethernet, una por edificio.
(Esto podría ser útil, incluso, si no hubiésemos dividido la Ethernet con el
fin de ayudar a localizarlos). Pero, antes de hacer esto, debemos estar muy
seguros de que el software
de todos los ordenadores puede manejar una
red que tiene tres números de red. Esta práctica se verá más detalladamente
en la sección 3.4.
También hemos de elegir una "máscara de subred", que será usada por el
software
del sistema para separar la parte de subred del resto de la
dirección. Hasta ahora hemos asumido que los dos primeros octetos son el
número de red y el siguiente es el número de subred. Para las direcciones de
clase B, el estándar especifica que los dos primeros octetos pertenecen al
número de red. Y, por otro lado, tenemos libertad para establecer el límite
del número de subred y el resto de la dirección. Es bastante usual utilizar
un octeto de número de subred, pero no es la única posibilidad. Veamos de
nuevo esta dirección de clase B, 128.6.4.3. Es fácil deducir que, si el
tercer octeto es usado como número de subred, entonces habrá 256 posibles
subredes y, en cada subred, habrá 256 posibles direcciones. (En realidad es
más acertado decir que disponemos de 254, ya que no es buena idea usar 0 ó
255 como números de subred o dirección). Supongamos que sabemos que nunca
vamos a tener más de 128 ordenadores por subred, pero es probable que
necesitemos más de 256 subredes (por ejemplo, un campus con una gran
cantidad de pequeños edificios). En ese caso, podríamos establecer 9 bits
como número de red, dejando 7 bits para el direccionamiento de cada subred.
Esta decisión queda plasmada en una máscara de bits, usando unos para los
bits usados por los números de red y de subred y ceros para los bits usados
para el direccionamiento individual. La máscara de red más común es
255.255.255.0. Si elegimos 9 bits para el número de subredes y 7 para las
direcciones, la máscara de subred sería 255.255.255.128.
Generalmente, es posible especificar la máscara de subred como parte de la
configuración del software
IP. Los protocolos IP también permiten a los
ordenadores que envíen un mensaje preguntando cuál es su máscara de subred.
Si nuestra red soporta el envío de estos mensajes, y hay, al menos, un
ordenador o gateway
de la red que conoce dicha máscara de subred,
posiblemente será innecesario especificarlo en cada uno de los restantes
ordenadores. Pero esta posibilidad puede traer muchos problemas. En caso de
que nuestra implementación TCP/IP diera una máscara de subred errónea, se
causaría una mala configuración en toda la red. Por lo tanto, es más seguro
poner cada máscara de subred explícitamente en cada sistema.
La mayoría del software
está desarrollado bajo el supuesto de que cada
red local tiene el mismo número de subred. Cuando existe un flujo hacia una
máquina con un distinto número de subred, el software
espera encontrar
un gateway
que pueda dirigirlo hacia esa subred. Veamos detalladamente
qué ocurre en este caso. Supongamos que tenemos las subredes 128.6.19 y
128.6.20 en la misma Ethernet. Consideremos las cosas que ocurren desde el
punto de vista de un ordenador con direcciòn 128.6.19.3. Dicho ordenador no
tendrá problemas para comunicarse con las máquinas de dirección 128.6.19.x.
Estas máquinas están en la misma subred, y nuestro ordenador simplemente
deberá enviar los datagramas al 128.6.20.2. Puesto que esta dirección indica
que está en una subred distinta, la mayoría del software
esperará
encontrar un gateway
que haga de puente entre ambas subredes. Por
supuesto, no existe un gateway
entre las "subredes" 128.6.19 y
128.6.20, puesto que están en la misma Ethernet. De aquí se deduce que
tenemos que encontrar una manera de indicarle al software
que el
128.6.20 se encuentra realmente en la misma Ethernet.
La mayoría de las implementaciones TCP/IP pueden manejar más de una subred
en la misma red. Por ejemplo, el Berkeley Unix nos permite hacerlo usando
una ligera modificación del comando usado para definir gateways
. Si,
por ejemplo, queremos que para pasar de la subred 128.6.19 a la subred
128.6.4 se use el gateway
con dirección 128.6.19.1, podemos usar el
comando
route add 128.6.4.0 128.6.19.1 1
Esto indica que para llegar a la subred 128.6.4 el flujo debe ser enviado a
través del gateway
128.6.19.1. El "1" se refiere a la "métrica de
enrutamiento". Si usamos la métrica "0", estamos diciendo que la subred de
destino está en la misma red y, por consiguiente, no se necesita ningún
gateway
. En nuestro ejemplo, deberemos usar en el sistema 128.6.19.3
route add 128.6.20.0 128.6.19.1 0
La dirección usada en el lugar de 128.6.19.1 es irrelevante. La métrica "0"
nos informa de que no va a usarse ningún gateway
, luego no se usará
dicha dirección. Sin embargo, deberá ampliarse una direción legal de la red
local.
Hay otro modo de manejar varias subredes sobre una red física. Este método
supone la desconfiguración de nuestros anfitriones o hosts
y, por ello,
es potencialmente peligrosa, si no sabemos exactamente lo que estamos
haciendo. Sin embargo, puede resultar más cómodo cuando trabajamos con una
gran cantidad de subredes en una red física. Un ejemplo de este tipo sería
una instalación que use bridges
, y usa subredes simplemente por
facilidades de administración. El truco está en configurar el software
de nuestros hosts
como si no usasen subredes. Así, nuestros hosts
no harán ninguna distinción entre las distintas subredes y, por tanto, no
habrá problemas para trabajar con todas ellas. Ahora, el único problema es
cómo comunicarnos con subredes que no estén en esta red de múltiples
subredes. Pero, si nuestros gateways
manejan proxy
ARP, ellos
resolverán este problema por nosotros. Este enfoque está especialmente
indicado cuando la misma red contiene múltiples subredes y, particularmente,
si se van a añadir algunas más en un futuro. Desgraciadamente, tiene dos
problemas:
hosts
con múltiples interfaces, deberemos ser muy
cuidadosos. En primer lugar, sólo debería haber máquinas con un interface en
la red con múltiples subredes. Por ejemplo, supongamos que disponemos de una
red que consta de varias Ethernets conectadas mediante bridges
; no podemos
tener una máquina con interfaces en dos de estas Ethernets, pero podemos
tener un sistema con un interface en esta red de subredes múltiples y otra
en otra subred apartada de ésta. En segundo lugar, cualquier máquina con
múltiples interfaces deberá conocer la verdadera máscara de subred, y
necesitará estar informada explícitamente de cuáles de las subredes están en
la red de múltiples subredes. Estas restricciones son consecuencia de que un
sistema con múltiples interfaces tiene que conocer qué interface ha de usar
en cada caso.
hosts
piensan que la red no está dispuesta en subredes, pero los
gateways
y los hosts
con varias interfaces piensan lo contrario,
tenemos aquí un foco potencial de confusión. Si un gateway
o
hosts
con varios interfaces envía una réplica a una ICMP de máscara de
red, dando la verdadera máscara de subred, alguno de los restantes
hosts
puede interceptarlo. La situación contraria también sería
posible. Esto significa que tendremos que:
gateways
lo conocen);
hosts
ignoran las réplicas ICMP.
A medida que establecemos una máscara de subred explícitamente, se supone
que los hosts
ignoran los ICMP de máscara de subred, así que deberemos
ser capaces de establecer diferentes máscaras en diferentes hosts
sin
causar ningún problema, siempre y cuando podamos establecer la máscara
explícitamente en todos ellos. Sin embargo, existen implementaciones IP que
cambiarán su máscara de subred cuando vean una réplica de ICMP de máscara de
subred.
Cuando tenemos más de una subred en una misma red física, hay que tener
cuidado respecto a las direcciones de broadcasting
. De acuerdo con los
últimos estándares, hay dos formas distintas para que un host
de la
subred 128.6.20 pueda enviar un broadcast
en la red local. Una es usar
la dirección 128.6.20.255. La otra es usar la dirección 255.255.255.255. La
dirección 128.6.20.255 dice, explícitamente, "todos los hosts
de la
subred 128.6.20"; la 255.255.255.255 expresa "todos los hosts
de mi red
local". Normalmente, ambas tienen el mismo efecto. Pero no lo tienen cuando
hay varias subredes en una red física. Si la red 128.6.19 está en la misma
red, también recibirá el mensaje enviado a 255.255.255.255. Sin embargo, los
hosts
con números 128.6.19.x no escucharán los mensajes enviados a
128.6.20.255. El resultado es que ahí tenemos dos tipos distintos de
direcciones de broadcast
con dos significados distintos. Esto conlleva
que debemos tener cuidado configurando el software
de red, para
asegurarnos de que nuestros broadcasting
llegan a donde queremos que lo
hagan.
Cuando solicitamos un número oficial de red se nos preguntará qué clase de
número de red necesitamos. Las posibles respuestas son A, B y C. La decisión
elegida limitará nuestro espacio de direcciones a usar. Las direcciones de
clase A ocupan un octeto; las de clase B, dos octetos, y la clase C, tres
octetos. Luego, hay más direcciones de clase C que direcciones de clase A,
pero las de clase C no pueden tener muchos hosts
. La idea que podemos
sacar de lo anterior es que debería haber pocas grandes redes, un número
moderado de redes de tamaño mediano y bastantes pequeñas redes. En la
siguiente tabla observamos dicha distinción:
Clase Rango 1er. octeto red resto direcciones posibles
A 1 - 126 p q.r.s 16777214
B 128 - 191 p.q r.s 65534
C 192 - 223 p.q.r s 254
Por ejemplo, la red 10 es de la clase A y por tanto tiene direcciones entre
10.0.0.1 y 10.255.255.254. Esto signfica 2543, que son sobre unos 16
millones de posibles direcciones (realmente, la red 10 tiene algunas
direcciones con octetos a cero, así que habrá algunas direcciones posibles
más). La red 192.12.88, una dirección de clase C, tendrá sus hosts
entre el 192.12.88.1 y el 192.12.88.254 y, por lo tanto, habrá 254 posibles
hosts
.
En general, deberemos elegir la clase menor que nos proporcione suficientes direcciones capaces de direccionar nuestra red, con sus posibles futuras ampliaciones. Aquellas organizaciones que usan ordenadores en varios edificios, probablemente necesitarán una dirección de clase B, suponiendo que vamos a usar subredes. (Y si vamos a tratar con distintos números de red, deberíamos solicitar varias direcciones de clase C). Las direcciones de clase A, normalmente, sólo se usan en grandes redes públicas y algunas pocas redes de grandes corporaciones.
En la asignación de Direcciones IP, la autoridad máxima es la IANA (Internet Assigned Number Authority). A escala continental, la IANA delega grandes bloques de direcciones IP a los denominados registros regionales, de los que, de momento, existen tres en el mundo:
Las organizaciones y usuarios finales han de obtener las direcciones IP necesarias para conectarse a Internet a través de su proveedor de acceso a Internet, quien a su vez las habrá obtenido bien de su proveedor de tránsito, bien del registro regional correspondiente.
En la mayoría de los casos, cada uno de los ordenadores tendrá su propia
dirección IP permanente. No obstante, hay algunas situaciones donde tiene
más sentido asignar direcciones dinámicamente. La mayoría de los casos que
manejan líneas IP constan de gateways
destinados principalmente a
microcomputadoras.
Es posible usar IP sobre líneas telefónicas. Uno de los protocolos para hacer esto es el SLIP ("Serial line IP"). SLIP se usa frecuentemente en, al menos, dos circunstancias distintas:
Vamos a usar el término "servidor SLIP" para referirnos a un sistema de
ordenador(es) que incluye una serie de modems, con los que otros sistemas
pueden conectarse usando SLIP. Se trata de un sistema que proporciona un
gateway
de nuestra red para usuarios de PC, o para otras redes que se
conectan usando SLIP.
Si tenemos varios PC's conectados mediante SLIP, muchas veces no es práctico usar una dirección IP propia para cada PC. Una de las razones puede ser que no haya suficientes direcciones. Para que el enrutamiento funcione correctamente, estos sistemas conectados deben tener sus direcciones en la misma subred que el servidor SLIP. Por lo general, hay solamente del orden de 256 direcciones disponibles en cada subred. Si el número de PC's que pueden conectarse es mayor que esa cifra, no podremos asignarles su propia dirección. Si, además, tenemos servidores SLIP en más de una subred, la asignación permanente de direcciones se hace aún más complicada. Si un usuario es capaz de llamar a dos servidores, su PC necesitaría dos direcciones, una para cada subred.
Para solucionar estos problemas, la mayoría de las implementaciones SLIP asignan las direcciones dinámicamente. Cuando un PC se conecta con el servidor SLIP, el servidor busca una dirección IP que no se esté usando y se la asigna al PC. La forma más simple de manejar esto es dando a cada servidor SLIP un rango de direcciones IP que controle y pueda asignar.
Cuando usamos este esquema, el software
SLIP debe comunicar al PC, de
alguna manera, qué dirección debe usar. Si cada PC tiene una dirección
permanente, tendríamos el problema contrario: cuando un PC se conecta con un
servidor debe de haber algún método para que el PC comunique al servidor su
dirección. Este problema debe ser estudiado cuidadosamente, porque en otro
caso alguien podría usar la dirección de otro y tener acceso a sus ficheros.
Desafortunadamente, no hay un estándar para manejar estos problemas de
direccionamiento con SLIP. Hay varias implementaciones SLIP que lo hacen,
pero todavía no hay un estándar. Hasta que no se elabore éste, deberemos
tener cuidado con el software
SLIP. Tenemos que asegurarnos de que
dicha asignación de dirección se lleva a cabo de la manera que queremos y
que nuestro servidor SLIP y los PC's tienen claro la forma en que se asignan
las direcciones.
Recomendamos dar direcciones permanentes a los PC's en aquellos casos en que los demás ordenadores tienen que ser capaces de conocer con qué PC están hablando. Este podría ser el caso de un PC para recibir correo privado, o cualquier otro servicio con transacciones delicadas. Y recomienda el direccionamiento dinámico cuando tenemos un gran número de PC's y las aplicaciones que utilizan para acceder a la red tienen sus propios mecanismos de seguridad.
Cuando usemos SLIP para conectar dos redes, hay que considerar tres
elecciones para el manejo de direcciones (teniendo en cuenta que no todo el
software
SLIP puede controlar los tres apartados):
software
de enrutamiento que permita interfaces
anónimos. En este caso, no serían necesarias las direcciones.
Si hacemos sólo una o dos conexiones a otro sistema, es bastante razonable usar un número de red para cada conexión. Este método es fácil de usar y limita los errores estadísticos.
Si tenemos muchas conexiones distintas, probablemente es mejor usar interfaces anónimos. Aunque si los sistemas de enrutamiento no lo soportan, debemos usar asignación dinámica.
Al igual que SLIP, PPP "Point to Point Protocol" es un protocolo serie distinto utilizado para enviar datagramas a través de una conexión serie, pero mejora algunas de las carencias del anterior. El PPP permite a las partes comunicantes negociar opciones como las direcciones IP y el tamaño máximo de los datagramas al comenzar la conexión, y proporciona permisos de conexión a los clientes (autorizaciones). Para cada una de estas capacidades, el PPP tiene un protocolo concreto.
A continuación, citaremos los elementos básicos que constituyen el PPP. Esta descripcion esta muy lejos de ser completa; si quiere saber mas sobre el PPP, lea sus especificaciones en el RFC 1548, asi como en la docena de RFCs que le acompañan.
En la parte más baja del PPP está el protocolo de Control de Conexión de Datos de Alto-Nivel, abreviadamente HDLC. ( En realidad, el HDLC es un protocolo mucho más general publicado por la Organización Internacional de Estándares, ISO ) que define los límites de las tramas PPP individuales, y proporciona un control de errores de 16 bit. Al contrario de lo que ocurría en las encapsulaciones SLIP más antiguas, una trama PPP es capaz de llevar paquetes de otros protocolos distintos al IP, como los IPX de Novell o Appletalk. El PPP consigue esto añadiendo a la trama básica HDLC un campo de control que identifica el tipo de paquete contenido en la trama.
El LCP, Protocolo de Control de Enlace, es utilizado en la parte más alta del HDLC para negociar las opciones concernientes a la conexión de datos, tales como la Unidad Máxima de Recepción (MRU) que establece el tamaño máximo del datagrama que una de las partes de la conexión acepta recibir.
Es perfectamente posible que un microcomputador forme parte de una red IP.
Pero hay una tendencia de que los micros utilicen distintas tecnologías de
red que la de los grandes sistemas. Esto es debido a que muchos de los
usuarios de micros empiezan a demandar un software
de red diseñado
específicamente para las necesidades de un micro, incluso para un particular
tipo de micro. Muchos usuarios están interesados en usar TCP/IP sin tener
que abandonar su red especial de micro, a la que están acostumbrados. Por
esta razón, hay un creciente número de productos, especialmente
gateways
, que dan acceso a los PC's tanto a redes orientadas a micros
como a TCP/IP.
En esta sección vamos a hablar del AppleTalk, de Apple, a modo de ejemplo. No obstante, existen productos similares para otros tipos de redes de micros. Hay que aclarar que el término AppleTalk se asocia a los protocolos de red de Apple, mientras que LocalTalk se asocia a una tecnología específica de par trenzado, en la que AppleTalk fue inicialmente implementada. Por tanto, el AppleTalk es análogo a los protocolos TCP/IP, mientras que LocalTalk es análogo a medio Ethernet.
Algunas compañías ofrecen gateways
para conectar una red AppleTalk
corriendo sobre LocalTalk, con redes IP corriendo sobre Ethernet. A pesar de
que hay varios productos de este tipo, la mayoría de ellos incluyen los
siguientes servicios:
gateway
, a
través del LocalTalk. Las aplicaciones TCP/IP de PC han sido escritas
usando unas librerías especiales que mezclan AppleTalk y TCP/IP. Las
utilidades AppleTalk se necesitan para llevar los datagramas hasta el
gateway
, donde se transformarán en datagramas 100% TCP/IP, antes
de dejarlos en la Ethernet.
gateway
, donde se transformarán
totalmente en AppleTalk, antes de dejarlos en la AppleTalk y lleguen al
PC.
gateways
de cada Apple realizarán
las conversiones necesarias antes de enviar los datagramas a la red IP.
Además, algunos gateways
pueden hacer traducciones a nivel de
aplicación. Por ejemplo, algunos gateways
pueden hacer traducciones
entre el sistema de ficheros de Apple y el sistema de fichero de red de Sun
(NFS). Esto permite a un PC acceder al sistema de ficheros Unix, donde el PC
usa el sistema de ficheros Apple, y el acceso al sistema Unix se hace
mediante el uso del sistema NFS, o sistema de ficheros de red (Network File
System ), de Sun.
Desafortunadamente, la gran flexibilidad de estos productos se traduce en
una gran complejidad. El tema de direcciones es especialmente complicado.
Por las mismas razones que SLIP, y PPP estos gateways
usan
frecuentemente asignación dinámica de direcciones IP. Para ello asignaremos
un rango de direcciones IP a cada gateway
. Cuando un PC intenta abrir
una conexión TCP/IP, el gateway
se hace con una dirección IP libre y se
la asigna al PC. Al igual que SLIP, en muchos casos necesitaremos elegir si
queremos que las direcciones se asignen de esta manera, o bien queremos que
cada PC tenga su propia dirección. Otra vez, la elección dependerá del
número de PC's que tengamos y de si tenemos aplicaciones capaces de usar la
dirección IP para identificar qué PC, en particular, es el que está
conectado.
El direccionamiento es mucho más complejo, debido a que AppleTalk tiene su
propia estructura de direcciones. Deberemos establecer una correspondencia
entre direcciones AppleTalk y números de red IP. También habrá una
correspondencia entre direcciones IP y AppleTalk, que se establecerá
dinámicamente en los gateways
.