PPP: Protocolo Punto a Punto

Introducción

La mayor parte de la infraestructura de redes de área extensa
está construida a partir de líneas alquiladas punto
a punto.

En la práctica, la
comunicación punto a punto se utiliza de diferentes
maneras. Actualmente, una de las formas más habituales de
conectarse a Internet para un usuario
común es a través de un módem y una
línea telefónica. En general, la PC llama al
router de su proveedor de Internet y así
actúa como host de la Red. Este método de
operación no es distinto a tener una línea
arrendada entre la PC y el router, excepto que la
conexión desaparece cuando el usuario termina la
sesión. Este concepto se
ilustra en la siguiente figura:

Tanto para la conexión por línea alquilada
de router a router como para la conexión
conmutada de host a router se requiere de un
protocolo punto a punto de enlace de datos en la
línea, para el manejo de marcos de control de
errores y las demás funciones de la
capa de enlace de datos.

Según nos acercamos al medio físico, la
diversidad de los mismos provoca que existan varios protocolos a
nivel de enlace de datos para
adaptarse a las peculiaridades de cada medio
físico.

Dos protocolos de
este nivel utilizados ampliamente en Internet son SLIP
(Serial Line Internet Protocol) y
PPP (Point to Point Protocol).

Si bien el protocolo SLIP
está específicamente diseñado para el
transporte de
tráfico TCP/IP, la
tendencia actual es hacia el uso cada vez mayor del protocolo PPP, ya
que también es apto para líneas telefónicas
conmutadas, siempre que nuestro proveedor de Internet disponga de este
protocolo para
atender nuestra llamada.

Al utilizar SLIP, es necesario conocer tanto nuestra
dirección IP como la de
nuestro proveedor, lo que puede causarnos problemas en
el caso de que este asigne dinámicamente las direcciones
(algo muy común actualmente). Igualmente, existe la
posibilidad de tener que configurar algunos parámetros
como pueden ser la máxima unidad de transmisión
(MTU), máxima unidad de recepción (MRU), el uso de
cabeceras de compresión, etc.

El PPP fue desarrollado por el IETF (Internet
Engineering Task Force) en 1993 para mejorar estas y algunas
otras deficiencias, y crear un estándar internacional, por
lo cual en este trabajo desarrollaremos principalmente el
protocolo PPP,
luego de lo que concluiremos con una breve comparación con
su par (SLIP).

DESARROLLO

¿Para qué sirve el protocolo
PPP?

El protocolo PPP proporciona un método
estándar para transportar datagramas multiprotocolo sobre
enlaces simples punto a punto entre dos "pares" (a partir de
aquí, y hasta el final de este trabajo, utilizaremos el
término "par" para referirnos a cada una de las
máquinas en los dos extremos del enlace -en inglés
es peer-).

Estos enlaces proveen operación bidireccional
full dúplex y se asume que los paquetes serán
entregados en orden.

Tiene tres componentes:

1. Un mecanismo de enmarcado para encapsular datagramas
multiprotocolo y manejar la detección de
errores.

2. Un protocolo de control de enlace
(LCP, Link Control
Protocol) para establecer, configurar y probar la
conexión de datos.

3. Una familia de
protocolos de
control de
red (NCPs,
Network Control
Protocols) para establecer y configurar los distintos
protocolos de
nivel de red.

Funcionamiento general

Para dar un panorama inicial del funcionamiento de este
protocolo en el caso comentado, en que un usuario de una PC
quiera conectarse temporalmente a Internet, describiremos
brevemente los pasos a seguir:

En primera instancia, la PC llama al router del
ISP (Internet Service Provider, proveedor del
servicio de
Internet), a través de un módem conectado a la
línea telefónica.

Una vez que el módem del router ha
contestado el teléfono y se ha establecido una
conexión física, la PC manda
al router una serie de paquetes LCP en el campo de
datos de uno o
más marcos PPP (esto será explicado con mayor
detalle más adelante). Estos paquetes y sus respuestas
seleccionan los parámetros PPP por usar.

Una vez que se han acordado estos parámetros se
envían una serie de paquetes NCP para configurar la capa
de red.

Típicamente, la PC quiere ejecutar una pila de
protocolos
TCP/IP, por lo que
necesita una dirección IP. No hay
suficientes direcciones IP para todos,
por lo que normalmente cada ISP tiene un bloque de ellas y asigna
dinámicamente una a cada PC que se acaba de conectar para
que la use durante su sesión. Se utiliza el NCP para
asignar la dirección de IP.

En este momento la PC ya es un host de Internet y
puede enviar y recibir paquetes IP. Cuando el usuario ha
terminado se usa NCP para destruir la conexión de la capa
de red y liberar la
dirección IP.

Luego se usa LCP para cancelar la conexión de la
capa de enlace de datos.

Finalmente la computadora
indica al módem que cuelgue el teléfono, liberando
la conexión de la capa física.

PPP puede utilizarse no solo a través de
líneas telefónicas de discado, sino que
también pueden emplearse a través de SONET o de
líneas HDLC orientadas a bits.

Configuración básica

Los enlaces PPP son fáciles de configurar. El
estándar por defecto maneja todas las configuraciones
simples. Se pueden especificar mejoras en la configuración
por defecto, las cuales son automáticamente comunicadas al
"par" sin la intervención del operador. Finalmente, el
operador puede configurar explícitamente las opciones para
el enlace, lo cual lo habilita para operar en ambientes donde de
otra manera sería imposible.

Esta auto-configuración es implementada a
través de un mecanismo de negociación de opciones extensible en el
cual cada extremo del enlace describe al otro sus capacidades y
requerimientos.

Entramado

La encapsulación PPP provee multiplexamiento de
diferentes protocolos de la capa de red sobre el mismo enlace. Ha
sido diseñada cuidadosamente para mantener compatibilidad
con el hardware
mayormente usado.

Sólo son necesarios 8 bytes adicionales para
formar la encapsulación cuando se usa dentro del entramado
por defecto. En ambientes con escaso ancho de banda, la
encapsulación y el entramado pueden requerir menos
bytes.

El formato de la trama completa es:

Todas las tramas comienzan con el byte indicador
"01111110". Luego viene el campo dirección, al que
siempre se asigna el valor
"11111111". La dirección va seguida del campo de
control, cuyo valor
predeterminado es "00000011". Este valor indica
un marco sin número ya que PPP no proporciona por
omisión transmisión confiable (usando
números de secuencia y acuses) pero en ambientes ruidosos
se puede usar un modo numerado para transmisión confiable.
El anteúltimo campo es el de suma de
comprobación, que normalmente es de 2 bytes, pero
puede negociarse una suma de 4 bytes. La trama finaliza con otro
byte indicador "01111110".

Debido a que los campos indicados anteriormente son
utilizados para encapsular la información fundamental del protocolo,
desde ahora nos centraremos en el siguiente esquema:

Campo protocolo

Este campo es de 1 o 2 bytes y su valor
identifica el contenido del datagrama en el campo de
información del paquete (cuando hablamos de
"paquete" nos estamos refiriendo al marco de la capa de enlace,
que es en la que opera el PPP; no debe confundirse con los de la
capa de red, manejados por IP). El bit menos significativo del
byte menos significativo debe ser 1 y el bit menos significativo
del byte más significativo debe ser 0. Los marcos
recibidos que no cumplan con estas reglas deben ser tratados como
irreconocibles.

Los valores en el
campo de protocolo dentro del rango de 0hex a 3hex identifican el
protocolo de capa de red de los paquetes específicos, y
valores en el
rango de 8hex a Bhex identifican paquetes pertenecientes al
protocolo de control de red asociado (NCPs). Los valores en
el campo de protocolo dentro del rango de 4hex a 7hex son usados
para protocolos con bajo volumen de
tráfico, los cuales no tienen asociados NCP. Valores en el
rango de Chex a Fhex identifican paquetes de los protocolos de
control de la capa de enlace (como LCP).

Campo información

Puede tener 0 o más bytes. Contiene el datagrama
para el protocolo especificado en el campo protocolo. La
máxima longitud para este campo, incluyendo el
relleno pero no incluyendo el campo de protocolo,
es determinada por la unidad máxima de recepción
(MRU), la cual es de 1500 bytes por defecto. Mediante
negociaciones, PPP puede usar otros valores para
la MRU.

A la información se le puede agregar un
relleno, con un número arbitrario de bytes, hasta
llegar a la MRU.

Operación del PPP

Para establecer comunicaciones
sobre un enlace punto a punto cada extremo del mismo debe enviar
primero paquetes LCP para configurar y testear el enlace de
datos. Después de que éste ha sido establecido, el
"par" debe ser autentificado. Entonces, PPP debe enviar paquetes
NCP para elegir y configurar uno o más protocolos de red.
Una vez que han sido configurados cada uno de los protocolos de
la capa de red elegidos, los datagramas de cada protocolo de capa
de red pueden ser enviados a través del enlace. El enlace
permanecerá configurado para la
comunicación hasta que una serie de paquetes NCP o LCP
cierren la conexión, o hasta que ocurra un evento externo
(por ej., que un timer de inactividad expire o que se
produzca una intervención del administrador de
la red).

Fases de la operación

En la siguiente figura se muestran las fases por las que
pasa una línea cuando es activada, usada y desactivada, a
través del protocolo PPP. Esta secuencia se aplica tanto a
las conexiones por módem como a las conexiones
router a router.

Fase de enlace muerto (capa física no
lista)

El enlace comienza y termina necesariamente en esta
fase. Cuando un evento externo (como una detección de
portadora) indica que la capa física está
lista para ser usada, PPP procederá con la fase de
establecimiento del enlace.

Típicamente, si se utiliza un módem, el
enlace volverá a esta fase automáticamente
después de la desconexión del mismo. En el caso de
un enlace hard-wired esta fase puede ser extremadamente
corta, tan solo hasta detectar la presencia del
dispositivo.

Fase de establecimiento del enlace

El protocolo de control de enlace (LCP) es usado para
establecer la conexión a través de un intercambio
de paquetes de configuración. Este intercambio está
completo y se ingresa en el estado
abierto de LCP una vez que un paquete de "reconocimiento de
configuración" ha sido enviado y recibido por
ambos.

Todas las opciones de configuración son asumidas
con sus valores por
defecto a menos que sean alteradas por un intercambio de paquetes
de configuración.

Es importante notar que solo las opciones de
configuración que son independientes de cada protocolo
particular de capa de red son manejadas por el LCP. La
configuración de los protocolos de capa de red
individuales es manejada por separado por los protocolos de
control de red (NCPs) durante la fase de red.

Cualquier paquete que no sea LCP recibido durante esta
fase debe ser descartado.

Fase de validación

En algunos enlaces puede ser deseable solicitar al "par"
que se autentifique a sí mismo antes de permitir el
intercambio de paquetes del protocolo de capa de red.

Por defecto, la validación o autenticación
no es obligatoria. Si una implementación desea que el
"par" se autentifique con algún protocolo de
validación específico, entonces ésta debe
solicitar el uso del protocolo de autenticación durante la
fase de establecimiento del enlace.

La autenticación debe tomar lugar tan pronto como
sea posible después del establecimiento del
enlace.

El progreso de la fase de autenticación a la fase
de red no debe ocurrir hasta que la autenticación
haya sido completada. Si ésta falla, el que realiza la
autenticación debe proceder a la fase de
terminación del enlace.

Durante esta fase, sólo son permitidos paquetes
del protocolo de control de enlace, el protocolo de
autenticación y el monitoreo de calidad de
enlace. Cualquier otro paquete recibido debe ser
descartado.

La autenticación debe proporcionar algún
método de
retransmisión, y se procederá a la fase de
terminación del enlace sólo luego de que se
ha excedido cierta cantidad de intentos de
autenticación.

Fase de red

Una vez que el PPP finalizó las fases anteriores,
cada protocolo de capa de red (como por ejemplo IP, IPX o
AppleTalk) debe ser configurado separadamente por el protocolo de
control de red (NCP) apropiado.

Cada NCP debe ser abierto y cerrado de a uno por
vez.

Fase abierta

Una vez que un NCP ha alcanzado el estado
abierto, PPP transportará los correspondientes paquetes
del protocolo de capa de red. Cualquier paquete recibido mientras
su NCP no esté en el estado
abierto debe ser descartado.

Durante esta fase el tráfico del enlace consiste
en cualquier combinación posible de paquetes LCP, NCP, y
de protocolo de capa de red.

Fase de terminación del enlace

PPP puede terminar el enlace en cualquier momento. Esto
puede ocurrir por la pérdida de la señal portadora,
una falla de autenticación, una falla de la calidad del
enlace, la expiración de un timer, o un cierre
administrativo del enlace.

LCP es usado para cerrar el enlace a través de un
intercambio de paquetes de "terminación". Cuando el enlace
ha sido cerrado, PPP informa a los protocolos de capa de red
así ellos pueden tomar la acción
apropiada.

Después del intercambio de paquetes de
"terminación", la implementación debe avisar a la
capa física que
desconecte la línea para forzar la terminación del
enlace, particularmente en el caso de una falla de
autenticación. El que envía una "solicitud de
terminación" debe desconectarse después de recibir
un "reconocimiento de terminación", o después de
que expire el timer correspondiente. El receptor de una
"solicitud de terminación" debe esperar al "par" para
desconectarse, y no lo debe hacer hasta que al menos haya pasado
cierto tiempo de
reiniciado después de enviar el "reconocimiento de
terminación". PPP procederá entonces con la fase de
enlace muerto.

Cualquier paquete recibido durante esta fase que no sea
LCP debe ser descartado.

La clausura del enlace por LCP es suficiente. No es
necesario que cada NCP envíe paquetes de
terminación. A la inversa, el hecho de que un NCP sea
cerrado no es razón suficiente para causar la
terminación del enlace PPP, aún si ese NCP era el
único actualmente en el estado
abierto.

Negociación automática de
opciones

La negociación de opciones es definida por
eventos,
acciones y
transiciones de estados. Los eventos incluyen
la recepción de comandos externos
(como apertura y clausura), expiración de timers, y
recepción de paquetes de un "par". Las acciones
incluyen el arranque de timers y la transmisión de
paquetes al "par".

Algunos tipos de paquetes ("no reconocimientos de
configuración", "rechazos de configuración",
"solicitudes de eco", "respuestas de eco", etc.) no son
diferenciados aquí ya que producen siempre las mismas
transiciones.

Estados

Algunos posibles estados son: "inicial" (la capa
más baja no está disponible y no ha ocurrido una
apertura), "starting" (ha sido iniciada una apertura pero
la capa más baja aún no está disponible),
"closed" (el enlace está disponible pero no ha
ocurrido una apertura), etc.

Eventos

Las transiciones y las acciones en la
negociación son causadas por eventos.

Algunos son: "up" (este evento ocurre cuando la
capa más baja indica que está lista para
transportar paquetes; típicamente es usado por los
procesos de
manejo y llamada de un módem, y también puede ser
utilizado por el LCP para indicar a cada NCP que el enlace
está entrando en la fase de red). Otro evento muy
común es "down" (cuando la capa más baja
indica que ya no está lista para transportar paquetes,
este evento también es generalmente utilizado por un
módem o por un LCP).

Acciones

Son causadas por eventos y
habitualmente indican la transmisión de paquetes y/o el
comienzo o parada de timers.

Algunas acciones son:
"evento ilegal" (esto indica acerca de un evento que no puede
ocurrir en una negociación implementada correctamente),
"capa hacia arriba" (esta acción indica a las capas
superiores que la negociación está entrando en
estado
"abierto"; típicamente es utilizada por el LCP para
indicar el evento "up" a un NCP, por un protocolo de
autenticación, o de calidad de
enlace).

Prevención de ciclos

El PPP hace intenta evitar ciclos mientras se
efectúa la negociación de opciones de
configuración. De todas formas, el protocolo no garantiza
que no ocurrirán ciclos. Como en cualquier
negociación es posible configurar dos implementaciones PPP
con políticas
conflictivas que nunca converjan finalmente. También es
posible configurar políticas
que converjan, pero que se tomen un tiempo
significativo para hacerlo.

Timers

Existen distintos tipos de timers. Por ejemplo,
el "timer de reiniciado" es utilizado para controlar el
tiempo de las
transmisiones de solicitud de configuración y los paquetes
de solicitud de terminación. La expiración de este
timer causa un evento de "tiempo cumplido"
y la retransmisión de la correspondiente "solicitud de
configuración" o el paquete de "solicitud de
terminación". Este timer debe ser configurable,
pero por defecto durará 3 segundos. Este tiempo
está pensado para bajas velocidades, como las
líneas telefónicas típicas.

Otro ejemplo de timer es el de
"terminación máxima", que es un contador de
reiniciado requerido para las solicitudes de terminación.
Indica el número de paquetes de "solicitudes de
terminación" enviados sin recibir un "reconocimiento de
terminación". Debe ser configurable pero por defecto se
establece en 2 transmisiones.

Protocolo de Control de Enlace (LCP)

El LCP es usado para acordar automáticamente las
opciones del formato de encapsulación, los límites
de manipulación de tamaño de paquete, detectar un
enlace con ciclos, otros errores comunes por mala
configuración, y terminar el enlace. Otras facilidades
opcionales provistas son: autenticación de la identidad de
los "pares" del enlace, y determinación de cuándo
el enlace está funcionando apropiadamente y cuándo
está fallando.

Formato de los paquetes LCP

Hay tres clases de paquetes LCP:

1. Paquetes de configuración de enlace: usados
para establecer y configurar el enlace ("solicitud de
configuración", "reconocimiento de configuración",
"no reconocimiento de configuración" y "rechazo de
configuración").

2. Paquetes de terminación de enlace: usados para
terminar el enlace ("solicitud de terminación" y
"reconocimiento de terminación").

3. Paquetes de mantenimiento
del enlace: usados para manejar y depurar el enlace ("rechazo de
código", "rechazo de protocolo", "solicitud de eco",
"respuesta de eco", "solicitud de descarte").

Un paquete LCP es encapsulado en el campo de información PPP, donde el campo de
protocolo PPP indica el tipo C021hex.

Básicamente, el formato de un paquete del
protocolo de control de enlace es el siguiente:

Campo código

Ocupa un byte y sirve para identificar el tipo de
paquete LCP. Cuando se recibe un paquete con un campo de
código desconocido, se transmite un paquete de "rechazo de
código".

Campo identificador

Es de un byte y ayuda en la comparación de las
solicitudes y respuestas.

Campo longitud

Es de dos bytes e indica la longitud del paquete LCP,
incluyendo los campos código, identificador, longitud y
datos. La longitud no debe exceder la MRU del enlace. Los bytes
fuera del rango del campo longitud son tratados como
relleno e ignorados al ser recibidos.

Campo datos

Pueden ser 0 o más bytes, indicados por el campo
longitud. El formato de los datos es determinado por el campo
código.

A continuación describiremos brevemente los
principales paquetes utilizados por el LCP:

Solicitud de configuración

Debe transmitirse para abrir una conexión. En el
campo de datos se incluirán las opciones de
configuración que el transmisor desee negociar (0 o
más). Todas estas opciones son negociadas
simultáneamente.

Reconocimiento de configuración

Si cada opción de configuración recibida
en una "solicitud de configuración" es reconocible y sus
valores son aceptables, la implementación receptora debe
transmitir un paquete de "reconocimiento". Estas opciones
reconocidas no deberán ser modificadas luego. Las opciones
reconocidas son enviadas en el área de datos del paquete
simultáneamente.

No reconocimiento de
configuración

Si cada opción de configuración es
reconocible pero algunos valores no son aceptables, se debe
transmitir un paquete de "no reconocimiento de
configuración". El campo de datos es completado
sólo con las opciones no aceptadas de la "solicitud de
configuración".

Al recibir un paquete de "no reconocimiento", el campo
de identificación debe ser comparado con el de la
última "solicitud de configuración", y cuando se
vuelva a enviar una "solicitud de configuración", las
opciones de la mismas deberán ser modificadas.

Rechazo de configuración

Este paquete será transmitido si se recibe una
"solicitud de configuración" en la que algunas opciones no
son reconocibles o aceptables para ser negociadas. El campo de
datos es completado sólo con las opciones de
configuración no aceptables.

Al recibir un "rechazo de configuración", el
campo identificador debe compararse con el de la última
solicitud de configuración.

Solicitud de terminación y reconocimiento de
terminación

Son utilizadas para terminar una conexión.
Primero se debe transmitir una "solicitud de terminación".
Estas solicitudes se seguirán transmitiendo hasta recibir
un "reconocimiento de terminación", hasta que la capa
inferior indique que se perdió la conexión, o hasta
que se haya transmitido un cierto número de solicitudes al
"par".

El campo de datos puede contener 0 o más bytes,
los cuales no son utilizados.

Rechazo de código

La recepción de un paquete LCP con un
código desconocido indica que el "par" está
operando con una versión diferente del protocolo. Esto
debe ser reportado al transmisor del código desconocido
por medio de un "rechazo de código". Al recibir un paquete
de este tipo acerca de un código que es fundamental para
la versión utilizada del protocolo, se deberá
reportar el problema y cesar la transmisión.

El campo de datos contiene una copia del paquete LCP que
está siendo rechazado.

Rechazo de protocolo

La recepción de un paquete PPP con un campo de
protocolo desconocido indica que el "par" está intentando
usar un protocolo no soportado. Esto ocurre usualmente cuando el
"par" intenta configurar un nuevo protocolo.

El campo de datos contiene en dos bytes el campo de
protocolo PPP del paquete que está siendo rechazado y a
continuación una copia del paquete rechazado.

Solicitud y respuesta de eco

Estos paquetes proveen al LCP de un mecanismo para
detectar ciclos en la capa de enlace de datos, que puede ser
utilizado en ambos sentidos. Es muy útil para ayudar en la
depuración, la determinación de la calidad del
enlace, de la performance y en varias funciones
más.

Luego de recibir una "solicitud de eco" se debe
transmitir la respuesta correspondiente.

El campo de datos contiene 4 bytes que son utilizados
para enviar un número llamado "mágico", que es
utilizado para detectar enlaces con ciclos. A continuación
puede ser transmitido cualquier valor binario
elegido por el transmisor.

Solicitud de descarte

El LCP incluye estos paquetes para proveer un mecanismo
de "hundimiento" de la capa de enlace de datos en el sentido
desde el sitio local hacia el remoto. Este mecanismo se utiliza
cuando se desea enviar paquetes para realizar alguna prueba, sin
que el "par" realice ninguna acción en función de
los mismos. Esto es útil para ayudar en la
depuración, el testeo de performance y algunas otras
funciones.

Los paquetes de "solicitudes de descarte" deben ser
ignorados al ser recibidos.

Opciones de configuración de
LCP

Estas opciones permiten la negociación o
modificación de las características por defecto de un enlace
punto a punto. Si no se incluyen opciones de configuración
en un paquete de solicitud de configuración, se asumen
los valores
por defecto para las mismas. El permitir valores por defecto para
cada opción otorga al enlace la capacidad de funcionar
correctamente sin negociaciones, pero sin embargo sin alcanzar
una performance óptima.

El formato de las opciones de configuración es el
siguiente:

Campo tipo

Este campo es de 1 byte e indica el tipo de la
opción de configuración.

Los valores posibles son: 0 (reservado), 1 (MRU), 3
(protocolo de autenticación), 4 (protocolo de calidad), 5
(número "mágico"), 7 (compresión del campo
de protocolo) y 8 (compresión de los campos de
dirección y control). Por supuesto, los valores
que acabamos de indicar deben transmitirse en binario.

Campo longitud

Es de 1 byte e indica la longitud del paquete,
incluyendo los campos tipo, longitud y datos.

Campo datos

Puede ser de 0 o más bytes, y contiene la
información específica de cada
opción a configurar. El formato y la longitud del campo de
datos son determinados por los campos de tipo y
longitud.

Protocolos de Control de Red (NCP)

Los enlaces punto a punto tienden a agravar muchos
problemas con
la familia
actual de protocolos de red. Por ejemplo, la asignación y
manejo de direcciones IP es especialmente dificultosa sobre
circuitos
conmutados de enlaces punto a punto (como los utilizados por los
módems).

Estos problemas son
manejados por una familia de
protocolos de control de red (NCPs), cada uno de los cuales
maneja las necesidades específicas requeridas por sus
respectivos protocolos de la capa de red, por lo cual su
definición detallada es tratada en forma separada de los
documentos
correspondientes al PPP.

COMPARACIÓN ENTRE PPP Y
SLIP

Además de los aspectos comentados en la
"Introducción" y las diferencias que se desprenden de la
sección de "Desarrollo", a
continuación enumeraremos en una tabla, y a modo de
resumen, algunas de las principales diferencias entre los
protocolos PPP y SLIP.

BIBLIOGRAFÍA

– "The Point-to-Point Protocol (PPP)", Request for
Comments 1661, July 1994, W. Simpson.

– "PPP LCP Extensions", Request for Comments 1570,
January 1994, W. Simpson.

– "PPP LCP Internationalization Configuration Option",
Request for Comments 2484, January 1999, G. Zorn.

– "PPP white paper", Morning Star
Technologies.

– "Redes de computadores",
1997, Tanenbaum, Andrew S.

– Diversos documentos
obtenidos en Internet.

Nota: debido a que utilizamos documentos RFC
originales, los mismos estaban en idioma inglés,
por lo cual podría ser posible que hayamos cometido un
pequeño error al escribir algún término
técnico.

Autor:

LÓPEZ, Oscar Raúl (24 años,
)

SACCO, Antonio (23 años, )

(Ambos autores son alumnos de 6to. año de la
carrera Ingeniería en Sistemas de
Información, de la Universidad
Tecnológica Nacional, Facultad Regional La
Plata.)