SERVIDOR PPPoe

1. INTRODUCCIÓN
Las tecnologías de acceso modernas se enfrentaban a varios objetivos
contradictorios como.
El deseo de conectar varios hosts de un sitio remoto a través de
Un mismo dispositivo de acceso de las instalaciones del cliente.
También se tenía como objetivo proporcionar control de acceso y funcionalidad
de facturación de una manera similar a los servicios de acceso telefónico
mediante PPP. En muchas tecnologías de acceso, la mayoría del método rentable
para adjuntar varios hosts al cliente dispositivo de acceso a las
instalaciones, es a través de Ethernet. Además, esto deseable para mantener el
costo de este dispositivo tan bajo como sea posible mientras que requiere poca
o ninguna configuración.
PPP sobre Ethernet (PPPoE) proporciona la capacidad de conectar una red
de los hosts a través de un simple dispositivo de acceso de puente a un acceso
remoto Concentrador. Con este modelo, cada host utiliza su propia pila PPP y
el usuario se presenta con una interfaz de usuario familiar. Acceso control,
facturación y tipo de servicio se pueden hacer en un por usuario, en lugar de
una base por sitio.
Para proporcionar una conexión punto a punto a través de Ethernet, cada PPP
Sesión debe aprender la dirección Ethernet del par remoto, así como establecer
un identificador de sesión único. PPPoE incluye un protocolo de descubrimiento
que proporciona esto.

2. PROTOCOLO SLIP

SLIP tiene sus orígenes en la implementación 3 COM UNET TCP/IP al principio

de los años 80. SLIP es simplemente una definición de una serie de caracteres,
para llevar paquetes IP en una línea serie. Al ser un protocolo de muy fácil
implementación no proporciona ni direccionamiento, ni identificación de tipo
de paquete, ni detección/corrección de errores ni mecanismos de compresión. Ya
en 1984 era posible la conexión de forma sencilla de host y encaminadores
(routers) mediante líneas serie. SLIP se puede emplear en líneas con
velocidades entre 1200 bps y 19.2 Kbps. Las configuraciones de SLIP más
comunes van a ser: host-host, host-router y router-router.
SLIP fue creado primeramente para la conectar dos estaciones de trabajo SUN a
Internet a través de una línea serie de discado usando un modem. Fue diseñado
por Rick Adams en 1984.
SLIP es un protocolo antiguo, con fallos que solo sirve para conexiones por
módem sencillas. Esto hizo que el PPP solo llegara a ser estándar de facto por
1
 SERVIDOR PPPoe

su gran difusión entre los sistemas UNIX. Su código fuente es gratuito y fácil
de transportar. Su misión es preparar los paquetes de datos de manera que
puedan transmitirse a través de una línea serie (conexión a través del módem),
en cambio estos solo pueden transmitirse byte a byte, marcándose el inicio y
el final de los paquetes.
SLIP (Serial Line Protocol, “Protocolo Internet para líneas Seriales”),
permite que su computadora utilice el Protocolo de Internet (IP) sobre un
enlace serie, como puede ser una línea telefónica. Cuando su computadora se
encuentra conectado a un proveedor de servicio SLIP (que le conecta a Internet
o a otra red), su computadora puede enviar y recibir paquetes IP como si
estuviese conectado a la red. Esto significa que cualquier software en cu
computadora que utilice el protocolo TCP/IP funcionará de forma adecuada.
Este protocolo se encuentra en la Capa de Enlace de Datos junto al PPP y HDLC.
SLIP esta definido bajo el RFC 1055.
Para conectarse a Internet, existen dos posibilidades: pertenecer a una red
local, en la que los ordenadores están físicamente conectados entre sí, o bien
conectarse vía módem con una red local. En este último caso se debe de
utilizar el protocolo SLIP o el PPP, aunque el PPP es el más extendido.
Es muy utilizado para conectar sistemas caseros a Internet. a través del
puerto serial RS-232 que se encuentra en casi todos las computadoras y modems.
Formato de SLIP.
Cada datagrama IP es terminado por el carácter especial C0. Para prevenir
ruido de línea se acostumbra mandar uno al principio también; de modo que se
de por terminada cualquier tipo de conexión errónea anterior.
Si el carácter C0 se presenta en el contenido del datagrama; se utiliza la
secuencia de dos bytes DB, DC el carácter DB es el carácter de escape de SLIP
(distinto al valor ASCII de ESC –1B--).
Si en el contenido se presenta el carácter de escape; se reemplaza por la
secuencia DB, DD.

2
 SERVIDOR PPPoe

SLIP deja a las capas superiores la detección y recuperación de marcos

perdidos.
El protocolo SLIP define dos caracteres especiales END y ESC que se
corresponden con el octal 300 y 333 respectivamente. El carácter ESC de SLIP
no debe confundirse con el carácter ESCape de ASCII. Si en los datos enviados
en un paquete SLIP aparece un código igual al carácter END, entonces este se
sustituye por dos caracteres que son un ESC y el octal 334. Si la coincidencia
es ahora con el carácter ESC entonces se sustituye con la secuencia ESC y el
octal 335. Para terminar los datos en el paquete entonces se envía un END. Al
no ser un protocolo estándar no esta definido un tamaño máximo de paquetes
para SLIP.
Servicios de SLIP
Durante una conexión SLIP, se pueden usar todos los servicios disponibles en
Internet, tales como Telnet, FTP, gráficos, sonidos, multimedia, fotografía,
animación, etc.
SLIP tiene varias limitaciones que lo hacen un protocolo no muy confiable.
- Admite solamente TCP/IP. No puedes utilizar SLIP para transferir
directamente otros protocolos de red, tales como IPX/SPX o NetBEUI.
- Se requiere una dirección IP estática. SLIP solicita al cliente que
configure todos los parámetros de configuración de TCP/IP, tales como las
direcciones IP, antes de establecer una conexión con el servidor.
- Depende de la autentificación de inicio de sesión basada en texto y,
normalmente, requiere de archivos de comandos para automatizar el proceso de
inicio de sesión.
- Transmite las contraseñas de autentificación mediante texto, lo que puede
ser peligroso para la seguridad porque las contraseñas no se encriptan durante
la autentificación del usuario.
Conclusiones.
El protocolo SLIP es empleado en conexiones solo de punto a punto a través de
una línea serie. Su modo de empleo es simple ya que su encapsulamiento es
sencillo por lo que es fácil el envío de datagramas de IP con este protocolo.
EL modo de encapsulamiento de este protocolo es solo el de poner un caracter
especial que indica el fin del datagrama o paquete para que el usuario que lo
reciba se de cuanta de el fin del mismo.
Por medio de este protocolo, una conexión hecha a través del mismo ofrece casi
todos los servicios que son ofrecidos por la Internet como son: e-mail, FTP,
envío de gráficos, etc.

3
 SERVIDOR PPPoe

Dado que este protocolo es muy simple y algo antiguo, es por lo tanto inseguro
ya que tiene muchas limitantes que en la actualidad es necesario en el caso de
las conexiones a Internet.
Se pueden detectar los paquetes de información que son enviados por este medio
y ser manipulados y/o alterados, es decir, SLIP es un protocolo no confiable.
Puede ser, si se le agregan otros mecanismos que regulen este problema
3. PROTOCOLO PUNTO A PUNTO (PPP)

3.1 INTRODUCION

La PPP fue desarrollada por el Grupo de Trabajo de Ingeniería de Internet

(IETF) como un medio de transmitir datos que contengan más de un protocolo de
red en el mismo punto a punto enlace de una manera estándar e independiente
del proveedor.
El PPP proporciona las conexiones directas sobre los circuitos síncronos y
asincrónicos. Trabajos PPP con varios protocolos de capa de red, como IP e
IPv6. PPP también tiene seguridad incorporada mecanismos como PAP (Protocolo
de Autenticación de Contraseña), CHAP (Desafío
Protocolo de apretón de manos de autenticación) y EAP (Protocolo de
autenticación extensible).
El protocolo PPP consta de los siguientes componentes principales:
Método para encapsular datagramas a través de enlaces en serie u otros
vínculos subyacentes. HDLC (Alto Control de enlace de datos de nivel), L2TP
(protocolo de túnel de capa 2) y PPPoE (punto a punto Protocolo a través de
Ethernet) proporcionan tales protocolos.
Un protocolo de control de enlaces (LCP) para establecer, configurar y probar
el enlace de datos Conexión.
Una familia de Protocolos de Control de Red (NCP) para establecer y configurar
diferentes protocolos de capa de red. PPP permite el uso simultáneo de
múltiples capas de red Protocolos. Un NCP común es el protocolo de control de
protocolo de Internet (IPCP). El método que PPP utiliza para llevar el tráfico
de red es abrir un enlace con un breve intercambio de Marcos. Una vez que el
link está abierto, el tráfico de red se lleva con muy poca sobrecarga. El
tráfico es transmitido como una serie de marcos de información sin numerar, lo
que significa que no hay enlace de datos se requieren confirmaciones y no se
envían retransmisiones. Una vez establecido el enlace, El PPP actúa como una
tubería de datos recta para los protocolos de la capa superior que encapsula.
3.2 GENERALIDADES

4
 SERVIDOR PPPoe

Protocolo punto a punto (PPP) (en inglés Point-to-Point Protocol), es un

protocolo del nivel de enlace de datos, utilizado para establecer una conexión
directa entre dos nodos de una red. Conecta dos enrutadores directamente sin
ningún equipo u otro dispositivo de red entre medias de ambos. Está
estandarizado en el documento RFC 1661. Puede proporcionar autenticación,
cifrado de la transmisión1 y compresión.
PPP es usado en varios tipos de redes físicas, incluyendo: cable serial, línea
telefónica, línea troncal, telefonía celular, especializado en enlace de radio
y enlace de fibra óptica como SONET (Synchronous Optical Network). También es
utilizado en las conexiones de acceso a Internet (publicitado como banda ancha
o broadband). Los proveedores de servicios de Internet (ISP) han usado PPP
para que accedan a Internet los usuarios de una línea de conmutación, ya que
los paquetes de IP no pueden ser transmitidos vía módem, sin tener un
protocolo de enlace de datos.
Dos derivados del PPP son:
Point-to-Point Protocol over Ethernet (PPPoE),
Point-to-Point Protocol over ATM (PPPoA).
Son usados comúnmente por los ISP para establecer una línea de abonado digital
(digital subscriber line, DSL) de servicios de internet para clientes.
Por tanto, se trata de un protocolo asociado a la pila TCP/IP de uso en
internet.
El protocolo punto a punto está diseñado para enlaces simples que
Paquetes de transporte entre dos pares. Estos enlaces proporcionan dúplex
completo
Operación bidireccional simultánea, y se supone que entregan
Paquetes en orden. Se pretende que PPP proporcione una solución común
Para una fácil conexión de una amplia variedad de hosts, puentes y enrutadores
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

5
 SERVIDOR PPPoe

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).

3.3 ENCAPSULACION PPP

La encapsulación PPP se utiliza para desambiguar datagramas multiprotocolo.
Esta encapsulación requiere un marco para indicar el comienzo y el final de la
encapsulación. Los métodos para proporcionar marcos se especifican en
documentos complementarios. Un resumen de la encapsulación PPP se muestra a
continuación.
Los campos se transmiten de izquierda a derecha.
+ ---------- + ------------- + --------- +
| Protocolo | Información | Relleno |
| 8/16 bits | * | * |
+ ---------- + ------------- + --------- +

Campo de protocolo

6
 SERVIDOR PPPoe

El campo de protocolo es uno o dos octetos, y su valor identifica el datagrama

encapsulado en el campo de Información del paquete.
El campo se transmite y recibe primero el octeto más significativo.
La estructura de este campo es consistente con el mecanismo de extensión ISO
3309 para los campos de dirección. Todos los protocolos deben ser impares; el
bit menos significativo del octeto menos significativo DEBE ser
igual a "1". Además, todos los protocolos DEBEN asignarse de modo que el
bit menos significativo del octeto más significativo sea igual a "0".
Los marcos recibidos que no cumplan con estas reglas deben tratarse como si
tuvieran un Protocolo no reconocido.
Los valores de campo de protocolo en el rango "0 ***" a "3 ***" identifican el
protocolo de capa de red de paquetes específicos y los valores en el
rango "8 ***" a "b ***" identifican los paquetes que pertenecen a los
Protocolos de Control de Red (NCP) asociados, si los hay.
Los valores de campo de protocolo en el rango "4 ***" a "7 ***" se utilizan
para protocolos con tráfico de bajo volumen que no tienen NCP asociado.
Los valores de campo de protocolo en el rango "c ***" a "f ***" identifican
los paquetes como protocolos de control de capa de enlace (como LCP)
valores actualizados del campo Protocolo se especifican en el
RFC "Números asignados"másreciente [ 2 ]. Esta especificación reserva
los siguientes valores:
Valor (en hexadecimal) Nombre del protocolo
0001 Protocolo de relleno
0003 a 001f reservado (transparencia ineficiente)
007d reservado (Control Escape)
00cf reservado (PPP NLPID)
00ff reservado (compresión ineficiente)
8001 a 801f sin usar
807d sin usar
80cf sin usar
80ff sin usar
C021 Protocolo de Control de Enlace
Protocolo de autenticación de contraseña C023
C025 Informe de Calidad del Enlace
C223 de autenticación por desafío mutuo de Protocolo de
Desarrolladores de nuevos protocolos deben obtener un número de la Internet
Assigned Numbers Authority (IANA), en IANA@isi.edu.
Campo de información.

7
 SERVIDOR PPPoe

El campo de información es cero o más octetos. El campo Información contiene

el datagrama para el protocolo especificado en el campo Protocolo.
La longitud máxima para el campo Información, incluido el Relleno, pero sin
incluir el campo Protocolo, se denomina Máximo Unidad de recepción (MRU), que
por defecto es de 1500 octetos. Mediante negociación, las implementaciones de
PPP con consentimiento pueden usar otros valores para la MRU.
Relleno.
En la transmisión, el campo de información PUEDE rellenarse con un número
arbitrario de octetos hasta la MRU. Es responsabilidad de cada protocolo
distinguir los octetos de relleno de la información real.
3.4 OPERACIÓN DEL ENLACE PPP
3.4.1 Visión general
Para establecer comunicaciones a través de un enlace punto a punto, cada
Extremo del enlace PPP DEBE enviar primero paquetes LCP para configurar y
probar el enlace de datos. Después de que se haya establecido el enlace, el
par PUEDE ser autenticado.
Luego, PPP DEBE enviar paquetes NCP para elegir y configurar uno o más
protocolos de capa de red. Una vez que se ha configurado cada uno de los
protocolos de capa de red elegidos, se pueden enviar datagramas de cada
Protocolo de capa de red a través del enlace.
El enlace permanecerá configurado para las comunicaciones hasta que los
Paquetes LCP o NCP explícitos cierren el enlace o hasta que ocurra algún
evento externo (un temporizador de inactividad caduca o la
Intervención del administrador de la red).
3.4.2 Diagrama de fases
En el proceso de configuración, mantenimiento y terminación del enlace punto a
punto, el enlace PPP pasa por varias fases distintas que se especifican en el
siguiente diagrama de estado simplificado:

3.4.3 Enlace muerto

8
 SERVIDOR PPPoe

El enlace necesariamente comienza y termina con esta fase. Cuando un evento

externo (como la detección del operador o la configuración del administrador
de la red ) indica que la capa física está lista para ser utilizada, PPP
procederá a la fase de Establecimiento del Enlace.
Durante esta fase, el autómata LCP (descrito más adelante) estará en los
estados inicial o inicial. La transición a la fase de Establecimiento de
Enlace indicará un evento Up al autómata LCP.
Nota de implementación:
Normalmente, un enlace volverá a esta fase automáticamente después de la
desconexión de un módem. En el caso de un enlace cableado, esta fase puede ser
extremadamente corta, simplemente lo suficientemente larga como para detectar
La presencia del dispositivo.
3.4.4 Fase de establecimiento de enlace
El protocolo de control de enlace (LCP) se utiliza para establecer la conexión
através de un intercambio de paquetes de configuración. Este intercambio se
completa y el estado de LCP abierto entró, una vez que un paquete Configure-
Ack (descrito más adelante) ha sido enviado y recibido.
Se supone que todas las opciones de configuración tienen los valores
predeterminados a menos que el intercambio de configuración las altere.
Consulte el capítulo sobre Opciones de configuración de LCP para obtener más
información. Es importante tener en cuenta que solo LCP configura las
opciones de configuración que son independientes de protocolos de capa de red
particulares . La configuración de protocolos individuales de capa de red se
maneja por protocolos de control de red (NCP) separados durante la
Fase del protocolo de capa de red. Cualquier paquete no LCP recibido durante
esta fase DEBE ser descartado silenciosamente.
La recepción de la solicitud de configuración de LCP provoca un retorno a la
fase de establecimiento de enlace desde la fase de protocolo de capa de red o
la fase de autenticación.
3.4.5 Fase de Autenticación
En algunos enlaces, puede ser deseable requerir que un par se autentique
antes de permitir el intercambio de paquetes de protocolo de capa de red .
Por defecto, la autenticación no es obligatoria. Si una implementación
desea que el par se autentique con algún protocolo de autenticación específico
, DEBE solicitar el uso de ese protocolo de autenticación durante la fase de
Establecimiento de Enlace.
La autenticación DEBE realizarse lo antes posible después del E
establecimiento del enlace . Sin embargo, la determinación de la calidad del
enlace PUEDE ocurrir simultáneamente. Una implementación NO DEBE permitir el

9
 SERVIDOR PPPoe

intercambio de paquetes de determinación de calidad de enlace para retrasar la

autenticación indefinidamente.
El avance de la fase de autenticación a la fase de protocolo de capa de red NO
DEBE ocurrir hasta que se haya completado la autenticación. Si la
autenticación falla, el autenti0cador debe continuar en su lugar a la fase de
terminación del enlace.
Solo el protocolo de control de enlace, el protocolo de autenticación y los
paquetes de monitoreo de calidad de enlace están permitidos durante esta fase.
Todos los demás paquetes recibidos durante esta fase DEBEN descartarse en
silencio.
Notas de implementación:
Una implementación NO DEBE fallar la autenticación simplemente debido al
tiempo de espera o la falta de respuesta. La autenticación DEBE permitir algún
método de retransmisión y proceder a la terminación del enlace
Fase solo después de que se hayan excedido varios intentos de autenticación La
implementación responsable de comenzar la fase de terminación de enlace es la
implementación que ha rechazado la autenticación a su par.
3.4.6 Fase de protocolo de capa de red
Una vez que PPP haya finalizado las fases anteriores, cada protocolo de capa
de red (como IP, IPX o AppleTalk) debe configurarse por separado mediante el
Protocolo de control de red (NCP) apropiado. Cada NCP PUEDE abrirse y cerrarse
en cualquier momento.
Nota de implementación:
Debido a que una implementación puede usar inicialmente una cantidad
significativa de tiempo para la determinación de la calidad del enlace, las
implementaciones deben evitar tiempos de espera fijos cuando esperan que sus
pares configuren un NCP.
Después de que un NCP haya alcanzado el estado Abierto, PPP transportará los
paquetes de protocolo de capa de red correspondientes.
Los Paquetes de protocolo recibidos cuando el NCP correspondiente
No estén el estado Abierto deben descartarse en silencio.
Nota de implementación:
Mientras LCP está en estado Abierto, cualquier paquete de protocolo que esté
no admitido por la implementación DEBE devolverse en un rechazo de protocolo
(descrito más adelante). Solo los protocolos admitidos se descartan
silenciosamente.
Durante esta fase, el tráfico de enlace consiste en cualquier combinación
posible de LCP, NCP y paquetes de protocolo de capa de red.
3.4.7 Fase de terminación de enlace

10
 SERVIDOR PPPoe

PPP puede terminar el enlace en cualquier momento. Esto puede suceder

debido a la pérdida del operador, la falla de autenticación, la falla de la
calidad del enlace,la expiración de un temporizador de inactividad o el cierre
administrativo del enlace.
LCP se utiliza para cerrar el enlace a través de un intercambio de
paquetes Terminate . Cuando se cierra el enlace, PPP informa a los
protocolos de la capa de red para que puedan tomar las medidas adecuadas.
Después del intercambio de paquetes terminando, la implementación se debe
indicar a la capa física que se desconecte para forzar la terminación del
enlace, particularmente en el caso de una falla de autenticación. El remitente
de la solicitud de terminación debe desconectar después de recibir un
Terminate-Ack, o después de que expire el contador de reinicio. El receptor de
una solicitud de terminación DEBE esperar a que el par se desconecte y no
deben desconectarse hasta que haya transcurrido al menos un tiempo de reinicio
después de enviar un reconocimiento de terminación. PPP debe proceder a la
fase Link Dead.
Cualquier paquete no LCP recibido durante esta fase DEBE ser descartado
silenciosamente.
3.5 LA OPCIÓN AUTÓMATA DE NEGOCIACIÓN
El estado finito autómata se define por eventos, acciones y transiciones de
estado. Los eventos incluyen la recepción de comandos externos como abrir y
Cerrar, la expiración del temporizador de reinicio y la recepción de paquetes
de un par. Las acciones incluyen el inicio del temporizador de reinicio y la
transmisión de paquetes al igual. Algunos tipos de paquetes - Configurar-Naks
y Configurar-Rechazar, o Rechazar código y Rechazar protocolo, o Solicitudes
de eco, Respuestas de eco y solicitudes de descarte - no se diferencian en las
descripciones del autómata. Como se describirá más adelante, estos paquetes
cumplen funciones diferentes. Sin embargo, siempre causan las mismas
transiciones.

Events Actions

Up = lower layer is Up tlu = This-Layer-Up

Down = lower layer is Down tld = This-Layer-Down
Open = administrative Open tls = This-Layer-Started
Close= administrative Close tlf = This-Layer-Finished

TO+ = Timeout with counter > 0 irc = Initialize-Restart-Count

TO- = Timeout with counter expired zrc = Zero-Restart-Count

RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request

RCR- = Receive-Configure-Request (Bad)
11
 SERVIDOR PPPoe

RCA = Receive-Configure-Ack sca = Send-Configure-Ack

RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej

RTR = Receive-Terminate-Request str = Send-Terminate-Request

RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack

RUC = Receive-Unknown-Code scj = Send-Code-Reject

RXJ+ = Receive-Code-Reject (permitted)
or Receive-Protocol-Reject
RXJ- = Receive-Code-Reject (catastrophic)
or Receive-Protocol-Reject
RXR = Receive-Echo-Request ser = Send-Echo-Reply
or Receive-Echo-Reply
or Receive-Discard-Request

3.5.1 Tabla de transición de estado

La tabla completa de transición de estado sigue. Los estados se indican
horizontalmente y los eventos se leen verticalmente. Las transiciones de
estado y las acciones se representan en la forma acción / nuevo estado. Las
acciones múltiples están separadas por comas y pueden continuar en líneas
sucesivas según lo requiera el espacio; Se pueden implementar múltiples
acciones en cualquier orden conveniente. El estado puede ir seguido de una
letra, que indica una nota explicativa al pie de página. El guión ('-') indica
una transición ilegal.

| State
| 0 1 2 3 4 5
Events| Initial Starting Closed Stopped Closing Stopping
------+-----------------------------------------------------------
Up | 2 irc,scr/6 - - - -
Down | - - 0 tls/1 0 1
Open | tls/1 1 irc,scr/6 3r 5r 5r
Close| 0 tlf/0 2 2 4 4
|
TO+ | - - - - str/4 str/5
TO- | - - - - tlf/2 tlf/3
|
RCR+ | - - sta/2 irc,scr,sca/8 4 5
RCR- | - - sta/2 irc,scr,scn/6 4 5
RCA | - - sta/2 sta/3 4 5
RCN | - - sta/2 sta/3 4 5
|
RTR | - - sta/2 sta/3 sta/4 sta/5
RTA | - - 2 3 tlf/2 tlf/3
|
RUC | - - scj/2 scj/3 scj/4 scj/5
RXJ+ | - - 2 3 4 5
RXJ- | - - tlf/2 tlf/3 tlf/2 tlf/3
|
RXR | - - 2 3 4 5

12
 SERVIDOR PPPoe

| State
| 6 7 8 9
Events| Req-Sent Ack-Rcvd Ack-Sent Opened
------+-----------------------------------------
Up | - - - -
Down | 1 1 1 tld/1
Open | 6 7 8 9r
Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4
|
TO+ | scr/6 scr/6 scr/8 -
TO- | tlf/3p tlf/3p tlf/3p -
|
RCR+ | sca/8 sca,tlu/9 sca/8 tld,scr,sca/8
RCR- | scn/6 scn/7 scn/6 tld,scr,scn/6
RCA | irc/7 scr/6x irc,tlu/9 tld,scr/6x
RCN |irc,scr/6 scr/6x irc,scr/8 tld,scr/6x
|
RTR | sta/6 sta/6 sta/6 tld,zrc,sta/5
RTA | 6 6 8 tld,scr/6
|
RUC | scj/6 scj/7 scj/8 scj/9
RXJ+ | 6 6 8 9
RXJ- | tlf/3 tlf/3 tlf/3 tld,irc,str/5
|
RXR | 6 7 8 ser/9

Los estados en los que se ejecuta el temporizador de reinicio son

identificables por la presencia de eventos TO. Solo las acciones Enviar-
Configurar-Solicitud, Enviar -Terminar-Solicitar y Cero-Reiniciar-Recuento
comienzan o reinician el temporizador de reinicio. El temporizador de reinicio
se detiene cuando se pasa de un estado en el que el temporizador se está
ejecutando a un estado en el que el temporizador no se está ejecutando.
Los eventos y acciones se definen de acuerdo con una arquitectura de paso de
mensajes , en lugar de una arquitectura de señalización. Si se desea una
acción para controlar señales específicas (como DTR), es probable que se
requieran acciones adicionales.

[ p ] Opción pasiva; ver Detenida discusión del estado.

[ r ] Opción de reinicio; ver Discusión de evento abierto.

[ x ] Conexión cruzada; ver discusión del evento RCA.

3.5.2 Estados

13
 SERVIDOR PPPoe

A continuación se incluye una descripción más detallada de cada estado del

autómata.
Inicial
En el estado Inicial, la capa inferior no está disponible (Abajo) y no se ha
abierto. El temporizador de reinicio no se ejecuta en el estado inicial.
Inicio.
El estado inicial es la contraparte abierta del estado inicial.Se ha iniciado
una apertura administrativa, pero la capa inferior todavía no está disponible
(abajo). El temporizador de reinicio no se ejecuta en el estado inicial.
Cuando la capa inferior está disponible (Arriba), se envía una Solicitud de
configuración.
Cerrado.
En el estado Cerrado, el enlace está disponible (Arriba), pero no se ha
abierto. Ocurrió. El temporizador de reinicio no se ejecuta en el estado
cerrado. Al recibir los paquetes de solicitud de configuración, se envía un
reconocimiento de terminación . Los Terminate-Acks se descartan
silenciosamente para evitar crear un bucle.
Detenido.
El estado detenido es la contraparte abierta del estado cerrado. Se ingresa
cuando el autómata está esperando un evento Down después de la acción This-
Layer-Finished, o después de enviar un Terminate-Ack. El temporizador de
reinicio no se ejecuta en el estado detenido.Al recibir los paquetes de
solicitud de configuración,se envía una respuesta adecuada . Tras la recepción
de otros paquetes, un Terminate-Ack es enviado. Los Terminate-Acks se
descartan silenciosamente para evitar crear un bucle.
Justificación:
El estado detenido es un estado de unión para la terminación del enlace, la
falla de la configuración del enlace y otros modos de falla del autómata.
Estos estados potencialmente separados se han combinado.
Hay una condición de carrera entre la respuesta del evento abajo (la acción
finalizada por esta capa) y el eventoRecibir-Configurar-Solicitar. Cuando
llega una solicitud de configuración antes del evento inactivo, el evento
inactivo se reemplazará devolviendo el autómata al estado inicial. Esto evita
el ataque por repetición.
Opción de implementación:
después de que el igual no responda a las solicitudes de configuración, una
implementación PUEDE esperar pasivamente a que el igual envíe solicitudes de
configuración. En este caso, la acción Fin deesta capano se utiliza para el
evento TO en los estados Req-Sent, Ack-Rcvd y Ack-Sent.

14
 SERVIDOR PPPoe

Esta opción es útil para circuitos dedicados, o circuitos que no tienen

señales de estado disponibles, pero no deben utilizarse para circuitos
conmutados.
Cierre
En el estado de Cierre, se realiza un intento de terminar la conexión. Se ha
enviado una solicitud de terminación y el temporizador de reinicio se está
ejecutando, pero aún no se ha recibido una confirmación de terminación.
Al recibir un Terminate-Ack, se ingresa al estado Cerrado.
Al expirar el temporizador de reinicio, se transmite una nueva solicitud de
terminación y se reinicia el temporizador de reinicio. Después de que el
temporizador de reinicio haya expirado los tiempos de finalización máxima, el
estado cerrado es ingresó.
Detención
El estado de detención es la contraparte abierta del estado de cierre.
Se ha enviado una solicitud de terminación y el temporizador de reinicio se
está ejecutando, pero aún no se ha recibido una confirmación de terminación.
Justificación:
El estado de detención ofrece una oportunidad bien definida para
terminar un enlace antes de permitir nuevo tráfico. Después de que el enlace
haya finalizado, puede ocurrir una nueva configuración a través de los estados
Detenido o Inicial.
Solicitud enviada
En el estado Solicitud enviada, se intenta configurar la conexión. Se ha
enviado una solicitud de configuración y se reinicia el temporizador se está
ejecutando, pero aún no se ha recibido un Configure-Ack no se ha enviado
ninguno.
Ack-Received
En el estado Ack-Received, se ha enviado una solicitud de configuración y se
ha recibido una confirmación de configuración. El temporizador de reinicio
todavía se está ejecutando, ya que aún no se ha enviado un Configure-Ack.
Ack-Enviado
En el estado Ack-Enviado, se han enviado una Solicitud de configuración y una
Configuración-Ack, pero aún no se ha Recibido una Configuración-Ack. El
temporizador de reinicio se está ejecutando, ya que aún no se ha recibido una
confirmación de configuración.
Abierto

15
 SERVIDOR PPPoe

En el estado Abierto, se ha enviado un Configure-Ack y recibido. El

temporizador de reinicio no se está ejecutando. Al entrar en el estado
Abierto, la implementación DEBE indicar a las capas superiores que ahora está
Arriba.
Por el contrario, al salir del estado Abierto, la implementación DEBE indicar
a las capas superiores que ahora está Abajo.
3.5.3 Eventos
Las transiciones y acciones en el autómata son causadas por eventos.
Arriba
Este evento ocurre cuando una capa inferior indica que está lista para
transportar paquetes. Típicamente, este evento es utilizado por un proceso de
manejo o llamada de módem , o por algún otro acoplamiento del enlace PPP a los
medios físicos , para indicar a LCP que el enlace está entrando en la
fase de Establecimiento de Enlace .
También puede ser utilizado por LCP para indicar a cada NCP que el enlace está
entrando en la fase del Protocolo de capa de red. Es decir, la acción This-
Layer-Up de LCP activa el evento Up en el NCP.
Abajo
Este evento ocurre cuando una capa inferior indica que no está listo para
transportar paquetes. Típicamente, este evento es utilizado por un
proceso de manejo o llamada de módem, o por algún otro acoplamiento del enlace
PPP a los medios físicos, para indicar a LCP que el enlace está entrando en la
fase de Enlace Inactivo.
También puede ser utilizado por LCP para indicar a cada NCP que el enlace está
saliendo de la fase del Protocolo de capa de red. Es decir, la
Acción This-Layer-Down de LCP activa el evento Down en el NCP.
Abrir
Este evento indica que el enlace está disponible administrativamente
para el tráfico; es decir, el administrador de la red (humano o programa)
ha indicado que se puede abrir el enlace. Cuando
se produce este evento y el enlace no está en estado Abierto, el
autómata intenta enviar paquetes de configuración al igual.
Si el autómata no puede comenzar la configuración (la
capa inferior está inactiva o un evento de cierre anterior no se ha
completado), el establecimiento del enlace se retrasa automáticamente.
Cuando se recibe una solicitud de terminación u otros eventos que
hacen que el enlace no esté disponible, el autómata progresará
a un estado en el que el enlace está listo para volver a abrirse. No
es necesaria una intervención administrativa adicional .

16
 SERVIDOR PPPoe

Opción de implementación:
La experiencia ha demostrado que los usuarios ejecutarán un
comando Abrir adicional cuando quieran renegociar el enlace. Esto podría
indicar que se deben negociar nuevos valores.
Dado que este no es el significado del evento Open, se
sugiere que cuando se ejecuta un comando Open user en los
estados Abierto, Cerrando, Deteniendo o Detenido, la
implementación emite un evento Down, seguido inmediatamente por un
evento Up. Se debe tener cuidado de que un evento Down intermitente
no pueda ocurrir desde otra fuente.
El Down seguido de un Up provocará una renegociación ordenada
del enlace, al avanzar a través de
Estado de solicitud enviada. Esto provocará la renegociación del
enlace, sin efectos secundarios dañinos.
Cerrar
Este evento indica que el enlace no está disponible para el tráfico;
es decir, el administrador de la red (humano o programa) ha
indicado que no se permite abrir el enlace. Cuando se produce este evento y el
enlace no está en el estado Cerrado, el autómata intenta finalizar la
conexión. Otros intentos de reconfigurar el enlace son denegados hasta que
ocurra un nuevo evento Open.
Nota de implementación:
cuando la autenticación falla, el enlace DEBE terminar, para evitar ataques
por repetición y denegación de servicio a otros usuarios. Dado que el enlace
está disponible administrativamente (por definición), esto se puede lograr
simulando un evento Cerrar al LCP, seguido inmediatamente por un evento
Abierto. Se debe tener cuidado de que un evento de cierre intermedio no pueda
ocurrir desde otra fuente.
El cierre seguido de una apertura provocará una terminación ordenada
del enlace, avanzando a través del estado de cierre hasta la detención , y la
acción de finalización de esta capa puede desconectar el enlace. El autómata
espera en los estados detenidos o de inicio para el siguiente intento de
conexión.
Tiempo de espera (TO +, TO-)
Este evento indica la caducidad del temporizador de reinicio. los
El temporizador de reinicio se usa para cronometrar las respuestas a los
paquetes Configurar-Solicitar y Terminar-Solicitar.
El evento TO + indica que el contador de reinicio continúa siendo

17
 SERVIDOR PPPoe

mayor que cero, lo que desencadena la retransmisión del paquete de solicitud

de configuración o solicitud de terminación correspondiente .
El evento TO indica que el contador de reinicio no es mayor que cero y que no
es necesario retransmitir más paquetes.
Recibir-Configurar-Solicitud (RCR +, RCR-)
Este evento ocurre cuando se recibe un paquete de Configuración-Solicitud del
par. El paquete de solicitud de configuración indica el deseo de abrir una
conexión y puede especificar las Opciones de configuración. Los El paquete
Configure-Request se describe más detalladamente en una sección posterior.
El evento RCR + indica que la Solicitud de configuración fue aceptable y
desencadena la transmisión de un Ack de configuración correspondiente .
El evento RCR indica que la solicitud de configuración fue inaceptable, y
desencadena la transmisión de un Configure-Nak o Configure-Reject
correspondiente.
Nota de implementación:
Estos eventos pueden ocurrir en una conexión que ya está en estado Abierto. La
implementación DEBE estar preparada para renegociar inmediatamente las
Opciones de configuración.Receive-Configure-Ack (RCA) Este evento ocurre
cuando se recibe un paquete de Configure-Ack válido del par. El paquete
Configure-Ack es una respuesta positiva a un paquete Configure-Request. Un
paquete fuera de secuencia o de otra manera inválido se descarta
silenciosamente.
Nota de implementación:
dado que el paquete correcto ya se recibió antes de alcanzar los estados Ack-
Rcvd o Abierto, es extremadamente improbable que llegue otro paquete de este
tipo. Como se especifica, todos los paquetes inválidos Ack / Nak / Rej se
descartan silenciosamente y no afectan las transiciones del autómata.
Sin embargo, no es imposible que un paquete formado correctamente
llegue a través de una conexión cruzada temporizada por coincidencia.
Es más probable que sea el resultado de un error de implementación.
Por lo menos, esta ocurrencia DEBE registrarse.

Recibir-Configurar-Nak / Rej (RCN)

Este evento ocurre cuando

se recibe un paquete válido de Configure-Nak o Configure-Reject del igual. Los
paquetes Configure-Nak y Configure-Reject son respuestas negativas a un
paquete Configure- Request. Un paquete fuera de secuencia o de otra manera
inválido sendescarta silenciosamente.

18
 SERVIDOR PPPoe

Nota de implementación:
Aunque Configure-Nak y Configure-Reject provocan la mismantransición de estado
en el autómata, estos paquetes tienen efectos significativamente diferentes en
las opciones de configuración enviadas en el paquete de solicitud de
configuración resultante.
Recibir-Terminar-Solicitud (RTR)
Este evento ocurre cuando se recibe un paquete de Terminar-Solicitud.
El paquete de solicitud de terminación indica el deseo del compañero de
cierra la conexión.
Nota de implementación:
Este evento no es idéntico al evento Cerrar (ver arriba), y
no anula los comandos Abrir del administrador de la red local. La
implementación debe estar preparada para recibir una nueva solicitud de
configuración sin .intervención del administrador de la red.

Receive-Terminate-Ack (RTA)
Este evento ocurre cuando se recibe un paquete Terminate-Ack del par.
El paquete Terminate-Ack suele ser una respuesta a un paquete Terminate-
Request. El paquete Terminate-Ack también puede indica que el par está en
estado Cerrado o Detenido, y sirve para volver a sincronizar la configuración
del enlace.
Recibir código desconocido (RUC)
Este evento ocurre cuando se recibe un paquete no interpretable del par. En
respuesta, se envía un paquete de rechazo de código.
Recibir-Código Rechazar, Recibir-Protocolo-Rechazar (RXJ +, RXJ-).
Este evento ocurre cuando se recibe un paquete de Código-Rechazo o un
Protocolo-Rechazo del par.
El evento RXJ + surge cuando el valor rechazado es aceptable, como un rechazo
de código de un código extendido o un rechazo de protocolo de un
NCP. Estos están dentro del alcance de la operación normal. Los la
implementación DEBE dejar de enviar el tipo de paquete infractor. ¡El evento
RXJ- surge cuando el valor rechazado es catastrófico, como un rechazo de
código de solicitud de configuración o un rechazo de protocolo de LCP! Este
evento comunica un error irrecuperable que termina la conexión.
Recibir solicitud de eco, Recibir respuesta de eco, Recibir solicitud de
descarte (RXR).
Este evento ocurre cuando se recibe un paquete de Solicitud de eco, Respuesta
de eco o Solicitud de descarte del par. El paquete Echo-Reply es una respuesta
a un paquete Echo-Request. No hay respuesta a un

19
 SERVIDOR PPPoe

paquete de respuesta de eco o solicitud de descarte.

3.6 COMPORTAMIENTO
Las acciones en el autómata son causadas por eventos y generalmente indican
la transmisión de paquetes y / o el inicio o la detención del temporizador de
reinicio.
Evento ilegal (-)
Esto indica un evento que no puede ocurrir en un
autómata implementado correctamente . La implementación tiene un error
interno, que se debe informar y registrar. No se realiza ninguna transición y
la implementación NO DEBE reiniciarse ni congelarse.
This-Layer-Up (tlu)
Esta acción indica a las capas superiores que el autómata está entrando en el
estado Abierto.Normalmente, esta acción es utilizada por el LCP para señalar
el evento Up a un NCP, Protocolo de autenticación o Protocolo de calidad de
enlace, O puede ser utilizado por un NCP para indicar que el enlace está
disponible para su tráfico de capa de red.

This-Layer-Down (tld)
Esta acción indica a las capas superiores que el autómata está dejando el
estado Abierto.Por lo general, el LCP utiliza esta acción para señalar el
evento Down a un NCP, un Protocolo de autenticación o un Protocolo de calidad
de enlace, o puede ser utilizada por un NCP para indicar que el enlace ya no
está disponible para su tráfico de capa de red.
This-Layer-Started (tls)
Esta acción indica a las capas inferiores que el autómata está
entrando en el estado inicial, y la capa inferior es necesaria para el
enlace. La capa inferior DEBERÍA responder con un evento Arriba cuando la
capa inferior esté disponible. Los resultados de esta acción dependen mucho de
la implementación.
Esta capa terminada (tlf)
Esta acción indica a las capas inferiores que el autómata está
entrando en los estados inicial, cerrado o detenido, y la
capa inferior ya no es necesaria para el enlace. La capa inferior DEBERÍA
responder con un evento Down cuando la capa inferior haya terminado.
Normalmente, esta acción PUEDE ser utilizada por el LCP para avanzar a la
fase de enlace inactivo, o PUEDE ser utilizada por un NCP para indicarle al
LCP que el enlace puede terminar cuando no hay otro PNC abiertos. Los
resultados de esta acción dependen mucho de la implementación.

20
 SERVIDOR PPPoe

Initialize-Restart-Count (irc)
Esta acción establece el contador de reinicio en el valor apropiado (Max-
Terminate o Max-Configure). El contador se disminuye para cada transmisión,
incluida la primera.
Nota de implementación:
además de establecer el contador de reinicio, la implementación
DEBE establecer el período de tiempo de espera en el valor inicial cuando
se utiliza el reinicio del temporizador de reinicio .
Zero-Restart-Count (zrc)
Esta acción establece el contador de reinicio en cero.
Nota de implementación:
esta acción permite que la FSA haga una pausa antes de proceder al estado
final deseado, permitiendo que el tráfico sea procesado por el par. Además de
poner a cero el contador de reinicio, la implementación DEBE establecer el
período de tiempo de espera en un valor apropiado.
Enviar-configurar-solicitud (scr)
Se transmite un paquete de configuración-solicitud. Esto indica el
deseo de abrir una conexión con un conjunto específico de configuración
Opciones El temporizador de reinicio se inicia cuando
se transmite el paquete de solicitud de configuración , para evitar la pérdida
de paquetes. El contador de reinicio disminuye cada vez que se envía una
solicitud de configuración.
Send-Configure-Ack (sca)
Se transmite un paquete Configure-Ack. Esto confirma la recepción de un
paquete de solicitud de configuración con un conjunto aceptable de
opciones de configuración.
Send-Configure-Nak (scn)
Se transmite un paquete Configure-Nak o Configure-Reject, según
corresponda. Esta respuesta negativa informa la recepción de un Simpson
Paquete de solicitud de configuración con un conjunto inaceptable de
opciones de configuración. Los paquetes Configure-Nak se utilizan para
rechazar un valor de opción de configuración0 para sugerir un nuevo valor
aceptable. Los paquetes Configure-Rejectse usan para rechazar toda negociación
sobre una o0pción de configuración, generalmente porque no se reconoce o
implementa.El uso de Configure-Nak versus Configure-Reject se
describemás detalladamenteen el capítulo Formatos de paquetes LCP.
Enviar-Terminar-Solicitud (str)
Se transmite un paquete de Terminar-Solicitud. Esto indica el Deseo de cerrar
una conexión. El temporizador de reinicio se inicia cuando se transmite el

21
 SERVIDOR PPPoe

paquete de solicitud de terminación, para evitar la pérdida de paquetes. El

contador de reinicio disminuye cada vez que se envía una solicitud de
terminación.
Send-Terminate-Ack (sta)
Se transmite un paquete Terminate-Ack. Esto reconoce la recepción de un
paquete de solicitud de terminación o sirve para sincronizar los autómatas.
Send-Code-Reject (scj)
Se transmite un paquete de Code-Reject. Esto indica la recepción de un tipo
desconocido de paquete.
Send-Echo-Reply (ser)
Se transmite un paquete de respuesta de eco. Esto reconoce el recepción de un
paquete de solicitud de eco.

3.7 EVITAR BUCLES

El protocolo hace un intento razonable de evitar los bucles de negociación de

la Opción de configuración. Sin embargo, el protocolo NO garantiza que no se
realizarán bucles. Como con cualquier negociación, es posible configurar dos
implementaciones de PPP con políticas en conflicto que
Nunca convergerán. También es posible configurar políticas que convergen, pero
que requieren un tiempo considerable para hacerlo. Los implementadores
deben tener esto en cuenta y DEBERÍAN implementar mecanismos de detección de
bucle o tiempos de espera superiores.

3.8 CONTADORES Y TEMPORIZADORES

Reiniciar temporizador
Hay un temporizador especial utilizado por el autómata. El temporizador de
reinicio se usa para cronometrar transmisiones de paquetes de solicitud de
configuración y solicitud de terminación. La caducidad del temporizador de
reinicio provoca un evento de tiempo de espera y la retransmisión del
correspondiente paquete de configuración o solicitud de terminación. El
temporizador de reinicio debe ser configurable, pero DEBE estar predeterminado
en tres (3) segundos.
Nota de implementación:
El temporizador de reinicio DEBE basarse en la velocidad del enlace.
El valor predeterminado está diseñado para enlaces de baja latencia de alta
velocidad ( líneas telefónicas típicas) de baja velocidad (2,400 a 9,600 bps).

22
 SERVIDOR PPPoe

Los enlaces de mayor velocidad, o enlaces con baja latencia de conmutación,

deberían tener tiempos de retransmisión correspondientemente más rápidos.En
lugar de un valor constante, el temporizador de reinicio puede comenzar en un
valor inicial pequeño y aumentar al valor final configurado. Cada valor
sucesivo menor que el valor final DEBE ser al
menos el doble del valor anterior. El valor inicial DEBE ser lo
suficientemente grande como para tener en cuenta el tamaño de los paquetes, el
doble del tiempo de ida y vuelta para la transmisión a la velocidad del
enlace, y al menos 100 milisegundos adicionales para permitir que el compañero
procese los paquetes antes de responder. Algunos circuitos agregan otros 200
milisegundos de retraso de satélite. Los tiempos
de ida y vuelta para los módems que funcionan a 14,400 bps se han medido en el
rango de 160 a más de 600 milisegundos.
Max-Terminate
Hay un contador de reinicio requerido para Terminate-Requests.
Max-Terminate indica el número de paquetes de Terminate-Request
enviados sin recibir un Terminate-Ack antes de asumir que el
par no puede responder. Max-Terminate DEBE ser configurable,
pero DEBERÍA tener por defecto dos (2) transmisiones.
Configuración máxima
Se recomienda un contador similar para las solicitudes de configuración.
Configuración máxima indica el número de paquetes de solicitud de
configuración enviados
sin recibir un Configure-Ack, Configure-Nak o
Configure-Reject válido antes de asumir que el par no puede
responder. La configuración máxima DEBE ser configurable, pero ddebe tener por
defecto diez (10) transmisiones.

Fallo máximo
Se recomienda un contador relacionado para Configure-Nak. Max-Failure
indica el número de paquetes Configure-Nak enviados sin enviar
un Configure-Ack antes de asumir que la configuración no es
convergente. Cualquier otro paquete Configure-Nak para las
opcionessolicitadas por paresse convierte en paquetes Configure-Reject, y
las opciones deseadaslocalmenteya no se agregan. Max-Failure DEBE ser

23
 SERVIDOR PPPoe

4 PROTOCOLO DE CONTROL DE ENLACE (LCP)

LCP funciona dentro de la capa de enlace de datos y cumple una función

en el establecimiento, la configuración y la prueba de la conexión de enlace
de datos. LCP establece el enlace punto a punto. LCP también negocia y
configura las opciones de control en el enlace de datos WAN, administradas por
los NCP.LCP proporciona la configuración automática de las interfaces en cada
extremo, incluido lo siguiente:
 Manejo de distintos límites en el tamaño de paquete
 Detección de errores comunes de configuración
 Finalización del enlace
 Determinación de cuándo un enlace funciona correctamente o cuándo falla
Una vez establecido el enlace, PPP también usa LCP para acordar
automáticamente los formatos de encapsulación, como la autenticación, la
compresión y la detección de errores.

24
 SERVIDOR PPPoe

4.1 Formatos de paquetes LCP

Hay tres clases de paquetes LCP:

• Tramas de establecimiento de enlace: Se utilizan para establecer y configurar

un enlace.
• Tramas de terminación del enlace: Se utilizan para terminar un enlace.
• Tramas de mantenimiento del enlace: Se utilizan para administrar y depurar un
enlace.
• Todos los paquetes del protocolo LCP son transportados en el campo de carga
de la trama del protocolo PPP. Lo que indica que la trama está transportando un
paquete LCP es el campo de protocolo, que debería contener el valor C02116

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:

Código Identificador Longitud Datos

(1 byte) (1 byte) (2 bytes) (variable)

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.

25
 SERVIDOR PPPoe

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.
26
 SERVIDOR PPPoe

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.

27
 SERVIDOR PPPoe

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:

Tipo Longitud Datos

(1 byte) (1 byte) (variable)

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.

28
 SERVIDOR PPPoe

5 PROTOCOLO DE CONTROL DE RED (NCP)

NCP (Network Control Protocol) permite la negociación opcional de
parámetros de configuración y opciones para encapsular multiprotocolo,
permitiendo entre ellos la asignación dinámica de dirección IP.

Proceso NCP

Una vez que se inició el enlace, LCP entrega el control al protocolo NCP
correspondiente.

Si bien en los inicios se diseñó para los paquetes IP, PPP puede transportar
datos de varios protocolos de capa de red mediante un enfoque modular en su
implementación. El modelo modular de PPP permite que LCP configure el enlace y
transfiera los detalles de un protocolo de red a un protocolo NCP específico.
Cada protocolo de red tiene un NCP correspondiente, y cada NCP tiene un RFC
correspondiente.

Hay NCP para IPv4, IPv6, IPX, AppleTalk y muchos otros. Los protocolos NCP
usan el mismo formato de paquetes que los protocolos LCP.

Una vez que LCP configuró y autenticó el enlace básico, se invoca el protocolo
NCP correspondiente para completar la configuración específica del protocolo
de capa de red que se usa. Cuando NCP configuró correctamente el protocolo de
capa de red, este se encuentra en estado abierto en el enlace LCP establecido.
En este momento, PPP puede transportar los paquetes correspondientes del
protocolo de capa de red.

5.1 PROTOCOLO DE CONTROL IP (IPCP)

El IPCP es un protocolo de control de red, Network Control Protocol, NCP para

configurar el IP en un enlace Point-to- Point Protocol (PPP). IPCP recién se
puede usar una vez establecido el nivel de enlace, es decir hasta la fase de
configuración de red. Cualquier paquete IPCP recibido antes de esta fase
deberá ser descartado. IPCP usa el mismo mecanismo de negociación de opciones
que Link Control Protocol (LCP).

29
 SERVIDOR PPPoe

Ejemplo de IPCP

Como ejemplo de cómo funciona la capa NCP, en la ilustración se muestra la

configuración NCP de IPv4, que es el protocolo de capa 3 más común. Una vez
que LCP estableció el enlace, los routers intercambian mensajes IPCP para
negociar opciones específicas del protocolo IPv4. IPCP es responsable de la
configuración, la habilitación y la deshabilitación de los módulos IPv4 en
ambos extremos del enlace. IPV6CP es un protocolo NCP con las mismas
responsabilidades para IPv6.

IPCP negocia dos opciones:

 Compresión: permite que los dispositivos negocien un algoritmo para comprimir

encabezados TCP e IP, y ahorrar ancho de banda. La compresión de encabezados
TCP/IP de Van Jacobson reduce los encabezados TCP/IP a un tamaño de hasta
3 bytes. Esto puede ser unas mejoras considerables en las líneas seriales
lentas, en particular para el tráfico interactivo.

 Dirección IPv4: permite que el dispositivo de inicio especifique una

dirección IPv4 para utilizar en el routaing IP a través del enlace PPP, o
para solicitar una dirección IPv4 para el respondedor. Antes de la llegada de

30
 SERVIDOR PPPoe

las tecnologías de banda ancha como los servicios de DSL y de cable módem,
los enlaces de red de dial-up normalmente usaban la opción de dirección IPv4.

Una vez que se completa el proceso NCP, el enlace pasa al estado abierto, y
LCP vuelve a tomar el control en la fase de mantenimiento del enlace. El
tráfico del enlace consta de cualquier combinación posible de paquetes LCP,
NCP y de protocolo de capa de red. Cuando se completa la transferencia de
datos, NCP termina el enlace del protocolo; LCP finaliza la conexión PPP.

4.2 Negociación de los enlaces PPP

FASES

1. Establecimiento del enlace (Abre conexión remota y negocia como se enviarán

los datos a través de esa ruta: MTU (máxima unidad de transferencia),
compresión de algunos campos de las tramas (como campos de dirección y
control), protocolo de autentificación de enlace, etc.)

2. Chequeo del enlace para determinar la calidad (opcional)

3. Configuración del protocolo capa red: IP, IPX. Datos.

4. Terminación (Normal por LCP o por evento físico como pérdida de señal de
portadora etc.)

Fase 1: Establecimiento del enlace y negociación de la configuración

• En esta fase cada dispositivo PPP envía paquetes LCP para configurar y
establecer el enlace de datos.

• Los paquetes LCP contienen un campo de opción de configuración que permite

que los dispositivos negocien el uso de opciones, como la unidad máxima de
transmisión (MTU), la compresión de determinados campos PPP y el protocolo de
autenticación de enlace. Si no se incluye ninguna opción de configuración en
un paquete LCP, se adopta el valor por defecto para esa configuración.

• Antes de que se pueda intercambiar cualquier datagrama de capa de red (por

ejemplo, IP), LCP primero debe abrir la conexión y negociar los parámetros de
configuración.

31
 SERVIDOR PPPoe

• Esta fase se completa cuando se ha enviado y recibido una trama de acuse de

recibo de configuración.

Fase 2: Determinación de la calidad de enlace

• LCP permite una fase opcional de determinación de la calidad del enlace a

continuación de la fase de establecimiento del enlace y negociación de la
configuración.

• En la fase de determinación de la calidad del enlace, el enlace se prueba para

determinar si la calidad del enlace es lo suficientemente buena como para
establecer los protocolos de capa de red. Además, una vez que se ha establecido
el enlace y que se ha elegido el protocolo de autentificación, se puede
autenticar la estación de trabajo del cliente o usuario.

• La autentificación, en caso de que se utilice, se lleva a cabo antes de que

comience la fase de configuración del protocolo de la capa de red. LCP puede
retardar la transmisión de la información del protocolo de capa de red hasta
que esta fase se haya completado.

• PPP soporta dos protocolos de autentificación: Protocolo de autentificación

de contraseña (PAP) y Protocolo de autentificación de saludo (CHAP). Ambos
protocolos se describen en detalle en RFC 1334, "Protocolos de autentificación
PPP".
Fase 3: Negociación de la configuración del protocolo de la capa de red

• Cuando LCP finaliza la fase de determinación de la calidad del enlace, los

protocolos de capa de red pueden ser configurados individualmente por el NCP
adecuado y se pueden activar y desactivar en cualquier momento.

• En esta fase, los dispositivos PPP envían paquetes NCP para seleccionar y
configurar uno o varios protocolos de capa de red (como IP). Cuando se ha
configurado uno de los protocolos de capa de red elegidos, se pueden enviar
datagramas desde cada uno de los protocolos de capa de red a través del enlace.
Si LCP cierra el enlace, informa esto a los protocolos de la capa de red, para
que puedan tomar las medidas adecuadas. Cuando PPP está configurado, puede
verificar el estado de LCP y NCP mediante el comando show interfaces.

32
 SERVIDOR PPPoe

Fase 4: Terminación

• LCP puede terminar el enlace en cualquier momento. Esto generalmente se realiza

a pedido del usuario, pero puede ocurrir debido a un suceso físico, como la
pérdida de una portadora o la expiración de un límite de tiempo.

5 Enlace de detección de ciclo

PPP detecta un ciclo de enlaces usando una característica que
envuelve números mágicos. Cuando los nodos envían mensajes PPP LCP, estos
mensajes pueden incluir unos números mágicos. Si una línea esté en ciclo,
el nodo recibe un mensaje LCP con su propio número mágico, en vez de
obtener un mensaje con el número.

5.1 Número Mágico

Este apartado nos proporciona una forma de detectar acoples internos y otras
anomalías en el nivel de enlace, y puede ser requerida por otra Opción de
Configuración, como por ejemplo la Opción de Configuración Monitorización de
la Calidad del Enlace.
Antes de que se solicite la Opción de Configuración Número Mágico, la
implementación debe escoger su Número Mágico. Se recomienda que éste sea
escogido lo más aleatoriamente posible para garantizar con una alta
probabilidad que la implementación obtenga un número único. Una buena forma de
elegir un número aleatorio único es comenzar con una semilla única. Las
fuentes de unicidad sugeridas incluyen números de serie, direcciones físicas
de hardware de red, relojes, etc. Las mediciones de tiempo que transcurre
entre eventos físicos tales como la recepción de paquetes en redes anexas,
tiempo de respuesta de un servidor, o la velocidad de escritura de un usuario
son semillas aleatorias especialmente buenas. También se recomienda utilizar
tantas fuentes aleatorias simultáneamente como sea posible. Cuando se recibe
una Petición de Configuración con una Opción de Configuración Número Mágico,
el Número Mágico recibido debería ser comparada con el Número Mágico de la
última Petición de Configuración enviada al extremo. Si los dos Números
Mágicos son diferentes no existe acople interno y por lo tanto el Número
Mágico debería ser reconocido. En el caso de que sean iguales, es posible,
pero no con total seguridad, que exista un acople interno y que la Petición de
Configuración recibida sea realmente la Petición de Configuración enviada
anteriormente. Para determinar esto, debería enviarse un Nak de Configuración
con un Número Mágico diferente. No debería enviarse al extremo otra Petición

33
 SERVIDOR PPPoe

de Configuración hasta que el desarrollo normal de la comunicación produjese

dicha acción (por ejemplo, hasta que se reciba un Nak de Configuración o
cuando el reloj de Reinicio termine).

La recepción de un Nak de Configuración con un Número Mágico diferente del que

tenía el último Nak de Configuración enviado al extremo prueba que el enlace
no es un acople interno e indica que el Número Mágico es único. Si el Número
Mágico es igual al enviado en el último Nak de Configuración aumenta la
posibilidad de un acople interno, y debería escogerse otro Número Mágico. En
ambos casos debería enviarse una nueva Petición de Configuración con el nuevo
Número Mágico obtenido. Si el acople interno continúa, dicho bucle (enviar
Petición de Configuración, recibir Petición de Configuración, enviar Nak de
Configuración, recibir Nak de Configuración) se repetirá una y otra vez. Si el
enlace no es un acople interno, esta secuencia puede llegar a ocurrir unas
pocas veces, pero es extremadamente improbable que ocurra repetidamente. Lo
más probable es que los Números Mágicos elegidos por cada extremo diverjan
rápidamente, terminando el bucle.

34
 SERVIDOR PPPoe

Descripción general del protocolo

PPPoE tiene dos etapas distintas. Hay una etapa de descubrimiento y un PPP
Etapa de sesión. Cuando un host desea iniciar una sesión PPPoE, primero debe
realizar descubrimiento para identificar la dirección MAC Ethernet del
dispositivo y establezca un ID de sesión de PPPoE. Mientras PPP define un
relación de igual a igual, descubrimiento es inherentemente un cliente-
servidor relación. En el proceso de descubrimiento, un host (el cliente)
descubre un concentrador de acceso (el servidor). Basado en la topología de
red, puede haber más de un concentrador de acceso que el El anfitrión puede
comunicarse con. La etapa de descubrimiento, permite al host que descubra
todos los concentradores de acceso y luego seleccione uno. Cuando El
descubrimiento se completa con éxito, tanto el Host seleccionado como el
control de acceso tienen la información que usará para construir su conexión
punto a punto a través de Ethernet.

fase de descubrimiento y fase de sesión PPP.

Fase de descubrimiento (PPPoED)

Cuando un equipo desea establecer una sesión PPPoE, debe primero efectuar una
fase de descubrimiento (PPPoED) para identificar la dirección MAC del otro
extremo y establecer un identificador de sesión PPPoE. En la fase de
descubrimiento, un equipo cliente descubre a un servidor PPPoE, denominado
habitualmente Concentrador de Acceso. Según la topología de la red, puede
haber más de un Concentrador de Acceso. La fase de descubrimiento permite al
cliente identificar a todos los Concentradores de Acceso y seleccionar uno de
ellos.
35
 SERVIDOR PPPoe

La fase de descubrimiento se divide en cuatro partes:

PADI (PPPoE Active Discovery Initiation) El cliente envía un paquete de inicio

a toda la red (paquete de broadcast), indicando los servicios que espera
recibir

PADO (PPPoE Active Discovery Offer) El concentrador de acceso, si puede

satisfacer los servicios requeridos, envía al cliente un paquete de oferta,
indicando los servicios que ofrece

PADR (PPPoE Active Discovery Request) El cliente elige, de entre todos los
Concentradores de Acceso que han enviado ofertas, aquél que mejor se ajusta a
sus necesidades y envía a dicho concentrador un paquete de solicitud de
establecimiento de sesión

PADS (PPPoE Active Discovery Session-confirmation) El concentrador de acceso

recibe la solicitud de establecimiento de sesión y envía un paquete de
confirmación de sesión , indicando el identificador de la sesión establecida.
A partir de este momento comienza la fase de sesión.

Fase de sesión

Una vez que la fase de descubrimiento se ha completado correctamente, tanto el

cliente como el Concentrador de Acceso tienen la información necesaria para
construir su conexión punto a punto sobre Ethernet. En la fase de sesión las
tramas intercambiadas entre los dos extremos corresponden a las de una sesión
PPP, con la particularidad de que dichas tramas van encapsuladas sobre tramas
Ethernet.

36
SERVIDOR PPPoe

37