El protocolo punto a punto sobre Ethernet ( PPPoE ) es un protocolo de red para encapsular tramas de protocolo punto a punto (PPP) dentro de tramas Ethernet . Apareció en 1999, en el contexto del auge del DSL como solución para tunelizar paquetes a través de la conexión DSL hasta la red IP del ISP , y desde allí al resto de Internet . Un libro sobre redes de 2005 señaló que "la mayoría de los proveedores de DSL utilizan PPPoE, que proporciona autenticación , cifrado y compresión ". [1] El uso típico de PPPoE implica aprovechar las funciones de PPP para autenticar al usuario con un nombre de usuario y contraseña, predominantemente a través del protocolo PAP y con menos frecuencia a través de CHAP . [2] Alrededor del año 2000, PPPoE también comenzaba a convertirse en un método de reemplazo para hablar con un módem conectado a una computadora o enrutador a través de una LAN Ethernet , desplazando el método anterior, que había sido USB . Este caso de uso, conectar enrutadores a módems a través de Ethernet, sigue siendo extremadamente común en la actualidad.
En el equipo de las instalaciones del cliente , PPPoE se puede implementar en un dispositivo de puerta de enlace residencial unificado que maneja tanto el módem DSL como las funciones de enrutamiento IP o, en el caso de un módem DSL simple (sin soporte de enrutamiento), el PPPoE se puede manejar detrás de él en un enrutador independiente solo para Ethernet o incluso directamente en la computadora de un usuario. (La compatibilidad con PPPoE está presente en la mayoría de los sistemas operativos, desde Windows XP , [3] Linux [4] hasta Mac OS X. [ 5] ) Más recientemente [ ¿cuándo? ] , algunas puertas de enlace residenciales basadas en GPON (en lugar de DSL) también utilizan PPPoE, aunque el estado de PPPoE en los estándares GPON es marginal.
PPPoE fue desarrollado por UUNET , Redback Networks (ahora Ericsson) y RouterWare (ahora Wind River Systems ) [6] y está disponible como RFC 2516 informativo.
En el mundo de DSL, se entendía comúnmente que PPPoE se ejecutaba sobre ATM (o DSL) como transporte subyacente, aunque no existe tal limitación en el protocolo PPPoE en sí. A veces, otros escenarios de uso se distinguen añadiendo como sufijo otro transporte subyacente. Por ejemplo, PPPoEoE, cuando el transporte es el propio Ethernet, como en el caso de las redes Metro Ethernet . (En esta notación, el uso original de PPPoE se denominaría PPPoEoA, aunque no debe confundirse con PPPoA , que es un protocolo de encapsulación diferente).
PPPoE ha sido descrito en algunos libros como un protocolo de " capa 2.5 ", [2] [7] en algún sentido rudimentario similar a MPLS porque puede usarse para distinguir diferentes flujos IP que comparten una infraestructura Ethernet, aunque la falta de conmutadores PPPoE hace Las decisiones de enrutamiento basadas en encabezados PPPoE limitan la aplicabilidad a ese respecto. [7]
A finales de 1998, el modelo de servicio DSL aún no había alcanzado la gran escala que permitiera reducir los precios a los niveles de los hogares. La tecnología ADSL se había propuesto una década antes. [8] Tanto los posibles proveedores de equipos como los operadores reconocieron que la banda ancha, como el módem por cable o DSL , eventualmente reemplazaría el servicio de acceso telefónico , pero el hardware (tanto en las instalaciones del cliente como LEC ) enfrentaba una importante barrera de costo de baja cantidad . Las estimaciones iniciales para la implementación de baja cantidad de DSL mostraron costos en el rango de $ 300 a $ 500 para un módem DSL y una tarifa de acceso de $ 300 al mes de la empresa de telecomunicaciones, [ cita necesaria ] que estaba mucho más allá de lo que pagaría un usuario doméstico. Por lo tanto, el enfoque inicial se centró en clientes de empresas pequeñas y domésticas para quienes una línea T1 de ~1,5 megabits (en ese momento entre $800 y $1500 por mes) no era económica, pero que necesitaban más de lo que el acceso telefónico o la RDSI podían ofrecer. Si un número suficiente de estos clientes allanaran el camino, las cantidades harían bajar los precios hasta donde el usuario de acceso telefónico de uso doméstico podría estar interesado.
El problema era que los clientes de pequeñas empresas tenían un perfil de uso diferente al de un usuario de acceso telefónico doméstico, que incluía:
Estos requisitos no se prestaban al retraso en el establecimiento de la conexión de un proceso de acceso telefónico ni a su modelo de una computadora a un ISP, ni siquiera al de muchos a uno que proporcionaba NAT más acceso telefónico. Se necesitaba un nuevo modelo.
PPPoE se utiliza principalmente:
Un problema al crear un protocolo completamente nuevo para satisfacer estas necesidades fue el tiempo. El equipo estuvo disponible de inmediato, al igual que el servicio, y una pila de protocolos completamente nueva ( Microsoft en ese momento defendía las células de cajero automático basadas en fibra para el escritorio, [9] y L2TP también se estaba gestando, pero no estaba). casi finalizado) llevaría tanto tiempo implementarse que la oportunidad podría pasar desapercibida. Se tomaron varias decisiones para simplificar la implementación y la estandarización en un esfuerzo por ofrecer una solución completa rápidamente.
PPPoE esperaba fusionar la extensa infraestructura Ethernet con el omnipresente PPP, permitiendo a los proveedores reutilizar su software existente y entregar productos en un plazo muy cercano. Básicamente, todos los sistemas operativos en ese momento tenían una pila PPP, y el diseño de PPPoE permitía un ajuste simple en la etapa de codificación de línea para convertir de PPP a PPPoE. [ cita necesaria ]
Las tecnologías WAN de la competencia (T1, RDSI) requerían un enrutador en las instalaciones del cliente. PPPoE utilizó un tipo de trama Ethernet diferente, lo que permitió que el hardware DSL funcionara simplemente como un puente , pasando algunas tramas a la WAN e ignorando las demás. La implementación de un puente de este tipo es mucho más sencilla que un enrutador.
RFC 2516 se publicó inicialmente como un RFC informativo (en lugar de un RFC de seguimiento de estándares ) por la misma razón: el período de adopción para un RFC de seguimiento de estándares era prohibitivamente largo.
PPPoE fue diseñado inicialmente para proporcionar una pequeña LAN con conexiones individuales independientes a Internet en general, pero también para que el protocolo en sí fuera lo suficientemente liviano como para no afectar el esperado mercado de uso doméstico cuando finalmente llegara. Si bien el éxito en el segundo asunto puede ser debatido (algunos se quejan de que 8 bytes por paquete es demasiado), PPPoE claramente logró generar suficiente volumen para reducir el precio del servicio a lo que pagaría un usuario doméstico.
Alrededor del año 2000, el protocolo PPPoE se usaba (i) para conectar un módem DSL a una computadora o enrutador, desplazando el método anterior de usar USB , o (ii) se usaba el trío de encabezados de protocolo PPP+PPPoE para conectar un enrutador a un nodo de red, un convertidor de protocolo, algo más arriba que pertenece al ISP o a un operador mayorista de larga distancia que a su vez se conecta a las redes IP del ISP y luego a Internet.
El primer caso de uso, la conexión de enrutador a módem, que involucra el llamado 'PPPoEoE' (el trío de protocolos PPPoE sobre una LAN Ethernet física), todavía se usa mucho hoy en día para conectar módems a enrutadores si se usa PPP.
El segundo caso de uso, en el que el trío de protocolos PPPoE se utiliza a través de uno o más enlaces de acceso a Internet que llegan a mayor o menor profundidad, según el consenso, solo se sigue utilizando por razones históricas. Sin embargo, dado que PPP sigue siendo popular entre algunos ISP, ya sea como protocolo de túnel, necesario cuando un ISP utiliza un operador/revendedor de acceso mayorista o porque se desean las características de PPP, o ambas.
Como se mencionó anteriormente, curiosamente, los encabezados MAC de Ethernet a veces se usan con encabezados PPPoE incluso cuando el protocolo Ethernet no está en uso o no está físicamente presente en una red Ethernet. Esto parece no tener ningún propósito aparte de agregar más encabezados innecesarios, lo que se conoce como bloat . Por ejemplo, en el caso, que se analiza a continuación, de PPPoEoA, donde no había Ethernet física, solo ATM , no solo se agregó una capa MAC de Ethernet innecesaria de cabecera, sino también una capa de adaptación de Ethernet adicional para que Ethernet encajara encima de ATM. .
En el segundo caso de uso, estos encabezados de protocolo adicionales añaden una gran cantidad de sobrecarga y, por lo tanto, perjudican ligeramente el rendimiento.
En el segundo caso de uso, el uso de PPP+PPPoE+Ethernet MAC se extiende a una distancia variable aguas arriba. Puede limitarse a la ' primera milla ': un par trenzado de cobre en ADSL o VDSL2 / FTTC que involucra módems y nada más, o también puede usarse más arriba extendiéndose a un 'servidor de acceso remoto de banda ancha' o 'concentrador de acceso' BRAS. que puede o no manejar el inicio de sesión, pero sin duda será un convertidor de protocolo de algún tipo. En un caso de ejemplo, PPPoE se extiende hacia arriba y termina en un nodo operado por un operador mayorista que se convierte al protocolo de túnel L2TP que conecta con los POP IP del ISP ('punto de presencia').
El PPPoE tiene dos etapas distintas:
Dado que las conexiones PPP tradicionales se establecen entre dos puntos finales a través de un enlace en serie o a través de un circuito virtual ATM que ya se ha establecido durante el acceso telefónico, todas las tramas PPP enviadas por cable seguramente llegarán al otro extremo. Pero las redes Ethernet son de acceso múltiple, donde cada nodo de la red puede acceder a todos los demás nodos. Una trama Ethernet contiene la dirección de hardware del nodo de destino ( dirección MAC ). Esto ayuda a que el marco llegue al destino previsto.
Por lo tanto, antes de intercambiar paquetes de control PPP para establecer la conexión a través de Ethernet, las direcciones MAC de los dos puntos finales deben conocerse entre sí para poder codificarlas en estos paquetes de control. La etapa PPPoE Discovery hace exactamente esto. También ayuda a establecer una ID de sesión que se puede utilizar para un mayor intercambio de paquetes.
Una vez que se conozca la dirección MAC del par y se haya establecido una sesión, comenzará la etapa de sesión.
Aunque el PPP tradicional es un protocolo de igual a igual , PPPoE es inherentemente una relación cliente-servidor, ya que varios hosts pueden conectarse a un proveedor de servicios a través de una única conexión física.
El proceso de descubrimiento consta de cuatro pasos entre la computadora host que actúa como cliente y el concentrador de acceso en el extremo del proveedor de servicios de Internet que actúa como servidor. Se describen a continuación. El quinto y último paso es la forma de cerrar una sesión existente.
PADI significa Iniciación de descubrimiento activo PPPoE. [10]
Si un usuario desea "conectarse" a Internet mediante DSL, entonces su computadora primero debe encontrar el concentrador de acceso DSL (DSL-AC) en el punto de presencia (POP) del proveedor de servicios de Internet del usuario . La comunicación a través de Ethernet sólo es posible a través de direcciones MAC . Como el ordenador no conoce la dirección MAC del DSL-AC, envía un paquete PADI a través de una transmisión Ethernet (MAC: ff:ff:ff:ff:ff:ff). Este paquete PADI contiene la dirección MAC de la computadora que lo envía.
Ejemplo de un paquete PADI:
Trama 1 (44 bytes en cable, 44 bytes capturados)Ethernet II, Fuente: 00:50:da:42:d7:df, Horario: ff:ff:ff:ff:ff:ffDescubrimiento de PPP sobre Ethernet Versión 1 Tipo 1 Iniciación de descubrimiento activo de código (PADI) ID de sesión: 0000 Longitud de carga útil: 24Etiquetas PPPoE Etiqueta: Nombre del servicio Etiqueta: Host-Uniq Datos binarios: (16 bytes)
Src. (=fuente) contiene la dirección MAC de la computadora que envía el PADI.
Dst. (=destino) es la dirección de transmisión Ethernet.
El paquete PADI puede ser recibido por más de un DSL-AC. Sólo deben responder los equipos DSL-AC que puedan servir la etiqueta "Nombre de servicio".
PADO significa oferta de descubrimiento activo PPPoE. [10]
Una vez que la computadora del usuario ha enviado el paquete PADI, el DSL-AC responde con un paquete PADO, utilizando la dirección MAC proporcionada en el PADI. El paquete PADO contiene la dirección MAC del DSL-AC, su nombre (p. ej. LEIX11-erx para T-Com DSL-AC en Leipzig ) y el nombre del servicio. Si más de un DSL-AC de POP responde con un paquete PADO, la computadora del usuario selecciona el DSL-AC para un POP en particular utilizando el nombre o servicio proporcionado.
A continuación se muestra un ejemplo de un paquete PADO:
Trama 2 (60 bytes en cable, 60 bytes capturados)Ethernet II, Origen: 00:0e:40:7b:f3:8a, Horario: 00:50:da:42:d7:dfDescubrimiento de PPP sobre Ethernet Versión 1 Tipo 1 Oferta de descubrimiento activo de código (PADO) ID de sesión: 0000 Longitud de carga útil: 36Etiquetas PPPoE Etiqueta: Nombre AC Datos de cadena: lpzbr001 Etiqueta: Host-Uniq Datos binarios: (16 bytes)
AC-Name -> Los datos de cadena contienen el nombre de AC, en este caso “lpzbr001” (Arcor DSL-AC en Leipzig)
Src. contiene la dirección MAC del DSL-AC.
La dirección MAC del DSL-AC también revela el fabricante del DSL-AC (en este caso Nortel Networks ).
PADR significa solicitud de descubrimiento activo PPPoE. [10]
La computadora del usuario envía un paquete PADR al DSL-AC luego de recibir un paquete PADO aceptable del DSL-AC. Confirma la aceptación de la oferta de conexión PPPoE realizada por el DSL-AC que emite el paquete PADO.
PADS significa confirmación de sesión de descubrimiento activo PPPoE. [10]
El DSL-AC confirma el paquete PADR anterior con un paquete PADS y con él se entrega una ID de sesión. La conexión con el DSL-AC para ese POP ya se ha establecido completamente.
PADT significa Terminación de descubrimiento activo PPPoE. [10] Este paquete finaliza la conexión al POP. Podrá enviarse desde el ordenador del usuario o desde el DSL-AC.
PPPoE se utiliza para conectar una PC o un enrutador a un módem a través de un enlace Ethernet y también se puede usar en el acceso a Internet a través de DSL en una línea telefónica en la pila de protocolo PPPoE sobre ATM (PPPoEoA) sobre ADSL . PPPoE sobre ATM tiene la sobrecarga más alta de los métodos de entrega DSL populares, en comparación con, por ejemplo, PPPoA (RFC 2364). [11] [12] [13] [14]
La cantidad de sobrecarga agregada por PPPoEoA en un enlace DSL depende del tamaño del paquete debido a (i) el efecto absorbente del relleno de celda ATM (que se analiza a continuación), que anula por completo la sobrecarga adicional de PPPoEoA en algunos casos, (ii) PPPoEoA + sobrecarga AAL5 que puede hacer que se requiera una celda ATM adicional completa de 53 bytes, y (iii) en el caso de paquetes IP, la sobrecarga PPPoE agregada a los paquetes que están cerca de la longitud máxima (" MRU " ) puede causar fragmentación de IP , lo que También implica las dos primeras consideraciones para los dos fragmentos de IP resultantes. [15] Sin embargo, ignorando la fragmentación de IP y ATM por el momento, los gastos generales del encabezado de protocolo para la carga útil de ATM debido a la elección de PPP + PPPoEoA pueden ser tan altos como 44 bytes = 2 bytes (para PPP) + 6 (para PPPoE) + 18 (Ethernet). MAC, variable) + 10 (RFC 2684 LLC, variable) + 8 (AAL5 CPCS). [11] Esta sobrecarga es la que se obtiene al utilizar la opción de encabezado LLC descrita en RFC 2684 para PPPoEoA. [13] [14]
Compare esto con un protocolo mucho más eficiente en términos de encabezado, PPP + PPPoA RFC 2364 VC-MUX sobre ATM+DSL, que tiene una sobrecarga de apenas 10 bytes dentro de la carga útil del cajero automático. (De hecho, simplemente 10 bytes = 2 bytes para PPP + cero para RFC 2364 + 8 (AAL5 CPCS).) [12] [14]
Esta cifra de sobrecarga de carga útil AAL5 de 44 bytes se puede reducir de dos maneras: (i) eligiendo la opción RFC 2684 de descartar el MAC FCS Ethernet de 4 bytes, lo que reduce la cifra de 18 bytes anterior a 14, y (ii) utilizando la opción RFC 2684 VC-MUX, cuya contribución de sobrecarga es de apenas 2 bytes en comparación con la sobrecarga de 10 bytes de la alternativa LLC. Resulta que esta reducción de gastos generales puede suponer una valiosa mejora de la eficiencia. Al utilizar VC-MUX en lugar de LLC, la carga útil del cajero automático es de 32 bytes (sin Ethernet FCS) o 36 bytes (con FCS). [11] [13]
ATM AAL5 requiere que siempre esté presente un final 'CPCS' de 8 bytes de longitud al final de la celda final ("justificada a la derecha") de la serie de celdas ATM que componen el paquete de carga útil AAL5. En el caso LLC, la sobrecarga total de carga útil del cajero automático es 2 + 6 + 18 + 10 + 8 = 44 bytes si el MAC FCS de Ethernet está presente, o 2 + 6 + 14 + 10 + 8 = 40 bytes sin FCS. En el caso más eficiente de VC-MUX, la carga útil del cajero automático es 2 + 6 + 18 + 2 + 8 = 36 bytes (con FCS), o 2 + 6 + 14 + 2 + 8 = 32 bytes (sin FCS).
Sin embargo, la verdadera sobrecarga en términos de la cantidad total de datos de carga útil del cajero automático enviados no es simplemente un valor adicional fijo: solo puede ser cero o 48 bytes (dejando de lado el escenario (iii) mencionado anteriormente, fragmentación de IP). Esto se debe a que las celdas ATM tienen una longitud fija con una capacidad de carga útil de 48 bytes, y agregar una mayor cantidad adicional de carga útil AAL5 debido a encabezados adicionales puede requerir que se envíe una celda ATM completa más que contenga el exceso. Las últimas una o dos celdas ATM contienen bytes de relleno según sea necesario para garantizar que la carga útil de cada celda tenga 48 bytes de longitud. [11] [13]
Un ejemplo: en el caso de un paquete IP de 1500 bytes enviado a través de AAL5/ATM con PPPoEoA y RFC2684-LLC, ignorando por el momento el relleno final de celda, se comienza con 1500 + 2 + 6 + 18 + 10 + 8 (AAL5 CPCS trailer) = 1544 bytes si el FCS Ethernet está presente, o + 2 + 6 + 14 + 10 + 8 = 40 bytes sin FCS. Para enviar 1544 bytes a través de ATM se requieren 33 celdas ATM de 48 bytes, ya que la capacidad de carga útil disponible de 32 celdas × 48 bytes por celda = 1536 bytes no es suficiente. Compare esto con el caso de PPP + PPPoA que a 1500 + 2 (PPP) + 0 (PPPoA: RFC 2364 VC-MUX) + 8 (avance CPCS) = 1510 bytes cabe en 32 celdas. Entonces, el costo real de elegir PPPoEoA más RFC2684-LLC para paquetes IP de 1500 bytes es una celda ATM adicional por paquete IP, una proporción de 33:32. [11] [12] [13] Entonces, para paquetes de 1500 bytes, PPPoEoA con LLC es ~3.125% más lento que PPPoA o las opciones óptimas de opciones de encabezado PPPoEoA.
Para algunas longitudes de paquetes, la sobrecarga DSL efectiva adicional real debido a la elección de PPPoEoA en comparación con PPPoA será cero si la sobrecarga de encabezado adicional no es suficiente para necesitar una celda ATM adicional en esa longitud de paquete en particular. Por ejemplo, un paquete de 1492 bytes de largo enviado con PPP + PPPoEoA usando RFC2684-LLC más FCS nos da una carga útil total del cajero automático de 1492 + 44 = 1536 bytes = 32 celdas exactamente, y la sobrecarga en este caso especial no es mayor que si estaban utilizando el protocolo PPPoA con encabezado eficiente, que requeriría 1492 + 2 + 0 + 8 = 1502 bytes de carga útil del cajero automático = 32 celdas también. [11] [13] El caso en el que la longitud del paquete es 1492 representa la eficiencia óptima para PPPoEoA con RFC2684-LLC en términos de relación, a menos que se permitan paquetes aún más largos.
Usar PPPoEoA con la opción de encabezado VC-MUX RFC2684 siempre es mucho más eficiente que la opción LLC, ya que la sobrecarga del cajero automático, como se mencionó anteriormente, es de solo 32 o 36 bytes (dependiendo de si es sin o con la opción Ethernet FCS en PPPoEoA). ) de modo que un paquete de 1500 bytes de largo que incluye todos los gastos generales de PPP + PPPoEoA usando VC-MUX equivale a un total de 1500 + 36 = 1536 bytes de carga útil ATM si el FCS está presente = 32 celdas ATM exactamente, ahorrando así una celda ATM completa. [11] [13]
Con paquetes cortos, cuanto más largo sea el encabezado, mayor será la probabilidad de generar una celda ATM adicional. El peor de los casos podría ser enviar 3 celdas ATM en lugar de dos debido a una sobrecarga de encabezado de 44 bytes en comparación con una sobrecarga de encabezado de 10 bytes, por lo que se necesita un 50% más de tiempo para transmitir los datos. Por ejemplo, un paquete TCP ACK sobre IPv6 tiene una longitud de 60 bytes y con una sobrecarga de 40 o 44 bytes para PPPoEoA + LLC, esto requiere cargas útiles de tres celdas ATM de 48 bytes. A modo de comparación, PPPoA tiene una sobrecarga de 10 bytes, por lo que 70 bytes en total caben en dos celdas. Entonces, el costo adicional de elegir PPPoE/LLC en lugar de PPPoA es un 50% adicional de envío de datos. Sin embargo, PPPoEoA + VC-MUX estaría bien: con una sobrecarga de 32 o 36 bytes, nuestro paquete IP todavía cabe en dos celdas.
En todos los casos, la opción más eficiente para el acceso a Internet ADSL basado en cajeros automáticos es elegir PPPoA (RFC2364) VC-MUX. Sin embargo, si se requiere PPPoEoA, entonces la mejor opción es siempre usar VC-MUX (a diferencia de LLC) sin Ethernet FCS, lo que genera una sobrecarga de carga útil del cajero automático de 32 bytes = 2 bytes (para PPP) + 6 (para PPPoE). + 14 (Ethernet MAC, sin FCS) + 2 (RFC 2684 VC-MUX) + 8 (remolque AAL5 CPCS).
Desafortunadamente, algunos servicios DSL requieren el uso de encabezados LLC con PPPoE y no permiten la opción VC-MUX, más eficiente. En ese caso, el uso de una longitud de paquete reducida, como imponer una MTU máxima de 1492, recupera la eficiencia con paquetes largos incluso con encabezados LLC y, como se mencionó anteriormente, en ese caso no se genera un desperdicio adicional de celda ATM.
En una LAN Ethernet, la sobrecarga para PPP + PPPoE es fija de 2 + 6 = 8 bytes , a menos que se produzca fragmentación de IP.
Cuando un módem DSL que habla PPPoE envía o recibe tramas Ethernet que contienen carga útil PPP + PPPoE a través del enlace Ethernet a un enrutador (o una sola PC que habla PPPoE), PPP + PPPoE contribuye con una sobrecarga adicional de 8 bytes = 2 (PPP) + 6 (PPPoE) incluido dentro de la carga útil de cada trama Ethernet. Esta sobrecarga adicional puede significar que se impone un límite de longitud máxima reducido (el llamado ' MTU ' o ' MRU ' ) de 1500 − 8 = 1492 bytes a (por ejemplo) los paquetes IP enviados o recibidos, en contraposición a los habituales 1500- Límite de longitud de carga útil de la trama Ethernet de bytes que se aplica a las redes Ethernet estándar. Algunos dispositivos admiten RFC 4638, que permite la negociación para el uso de tramas Ethernet no estándar con una carga útil Ethernet de 1508 bytes, a veces denominadas " tramas baby jumbo ", lo que permite una carga útil PPPoE completa de 1500 bytes. Esta capacidad es ventajosa para muchos usuarios en los casos en que las empresas que reciben paquetes IP han elegido (incorrectamente) bloquear todas las respuestas ICMP para que no salgan de su red, una mala práctica que impide que el descubrimiento de MTU de ruta funcione correctamente y que puede causar problemas a los usuarios que acceden a dichas redes. si tienen una MTU de menos de 1500 bytes.
El siguiente diagrama muestra un escenario en el que un módem ADSL conectado a Ethernet actúa como un convertidor de protocolo PPPoE a PPPoA y el proveedor de servicios ofrece un servicio PPPoA y no comprende PPPoE. No hay ningún PPPoEoA en esta cadena de protocolo. Este es un diseño con una eficiencia de protocolo óptima para un módem ADSL independiente conectado a un enrutador mediante Ethernet.
En esta tecnología alternativa, PPPoE es simplemente un medio para conectar módems DSL a un enrutador solo Ethernet (nuevamente, o a una única PC host). Aquí no se trata del mecanismo empleado por un ISP para ofrecer servicios de banda ancha.
Los módems Draytek Vigor 110, 120 y 130 funcionan de esta forma.
Al transmitir paquetes con destino a Internet, el enrutador Ethernet que habla PPPoE envía tramas Ethernet al módem DSL (también que habla PPPoE). El módem extrae tramas PPP de las tramas PPPoE recibidas y envía las tramas PPP al DSLAM encapsulándolas de acuerdo con RFC 2364 (PPPoA), convirtiendo así PPPoE en PPPoA.
En el diagrama, el área que se muestra como 'backbone' también podría ser ATM en redes más antiguas; sin embargo, su arquitectura depende del proveedor de servicios. En un diagrama más detallado y más específico del proveedor de servicios, habría celdas de tabla adicionales en esta área.
Dado que la conexión punto a punto establecida tiene una MTU inferior a la de Ethernet estándar (normalmente 1492 frente a 1500 de Ethernet), a veces puede causar problemas cuando Path MTU Discovery es derrotado por firewalls mal configurados . Aunque las MTU más altas se están volviendo más comunes en las redes de los proveedores, generalmente la solución es utilizar la "sujeción" o "reescritura" de TCP MSS (tamaño máximo de segmento), mediante el cual el concentrador de acceso reescribe el MSS para garantizar que los pares TCP envíen datagramas más pequeños. Aunque la sujeción de TCP MSS resuelve el problema de MTU para TCP, es posible que otros protocolos como ICMP y UDP aún se vean afectados.
RFC 4638 permite que los dispositivos PPPoE negocien una MTU superior a 1492 si la capa Ethernet subyacente es capaz de generar tramas gigantes .
Algunos proveedores ( Cisco [16] y Juniper , [ cita requerida ] por ejemplo) distinguen PPPoE[oA] de PPPoEoE (PPPoE sobre Ethernet), que es PPPoE que se ejecuta directamente sobre Ethernet u otras redes IEEE 802 o sobre Ethernet puenteado sobre ATM , en para distinguirlo de PPPoEoA (PPPoE sobre ATM), que es PPPoE ejecutándose sobre un circuito virtual ATM utilizando RFC 2684 y encapsulación SNAP de PPPoE. [ cita necesaria ] (PPPoEoA no es lo mismo que el protocolo punto a punto sobre ATM (PPPoA), que no utiliza SNAP).
Según un documento de Cisco, "PPPoEoE es una variante de PPPoE donde el protocolo de transporte de capa 2 ahora es Ethernet o VLAN 802.1q en lugar de ATM. Este método de encapsulación se encuentra generalmente en entornos Metro Ethernet o Ethernet de multiplexor de acceso a línea de abonado digital (DSLAM). "El modelo de implementación común es que este método de encapsulación se encuentra típicamente en hoteles u edificios de múltiples inquilinos. Al entregar Ethernet al suscriptor, el ancho de banda disponible es mucho más abundante y aumenta la facilidad de entrega de servicios adicionales". [dieciséis]
Es posible encontrar módems DSL, como el Draytek Vigor 120, donde PPPoE se limita al enlace Ethernet entre un módem DSL y un enrutador asociado, y el ISP no habla PPPoE en absoluto (sino PPPoA ). [17]
ZTE ha patentado un determinado método para utilizar PPPoE junto con GPON (que implica la creación de una VLAN a través de OMCI) . [18]
Se informa que PPPoE sobre GPON es utilizado por proveedores de servicios minoristas como Internode de la Red Nacional de Banda Ancha de Australia , [19] Orange de Francia, [20] Globe Telecom de Filipinas [21] y Aruba FTTH de Italia [22] en redes públicas GPON de OpenFiber .
RFC 6934, "Aplicabilidad del mecanismo de control de nodos de acceso a redes de banda ancha basadas en PON", que aboga por el uso del protocolo de control de nodos de acceso en PON para, entre otras cosas, autenticar el acceso de los suscriptores y administrar sus direcciones IP, y cuyo primer autor es un empleado de Verizon, excluye PPPoE como una encapsulación aceptable para GPON: "La encapsulación de protocolo en BPON se basa en una encapsulación multiprotocolo sobre ATM Adaptation Layer 5 (AAL5), definida en [RFC2684]. Esto cubre PPP sobre Ethernet (PPPoE, definido en [RFC2516]) o IP sobre Ethernet (IPoE). La encapsulación del protocolo en GPON es siempre IPoE." [23]
El estándar 10G-PON (XG-PON) ( G.987 ) proporciona autenticación mutua 802.1X de ONU y OLT, además del método OMCI procedente de G.984 . [24] G.987 también agrega soporte para autenticar otros equipos en las instalaciones del cliente más allá de la ONU (por ejemplo, en una MDU), aunque esto se limita a los puertos Ethernet, también manejados a través de 802.1X. (Se supone que la ONU espía los mensajes RADIUS encapsulados por EAP en este escenario y determina si la autenticación fue exitosa o no). [25] Existe cierto soporte mínimo para PPPoE especificado en los estándares OMCI, pero solo en términos de que la ONU pueda para filtrar y agregar etiquetas VLAN para el tráfico en función de su encapsulación (y otros parámetros), lo que incluye PPPoE entre los protocolos que la ONU debe poder discernir. [26]
El TR-200 del Broadband Forum "Uso de EPON en el contexto de TR-101" (2011), que también pertenece a 10G-EPON , dice "El OLT y la ONU de múltiples suscriptores DEBEN poder realizar el agente intermedio PPPoE función, como se especifica en la Sección 3.9.2/TR-101." [27]
Un libro sobre Ethernet en la primera milla señala que obviamente se puede usar DHCP en lugar de PPPoE para configurar un host para una sesión IP, aunque señala que DHCP no es un reemplazo completo para PPPoE si también se desea algo de encapsulación (aunque los puentes VLAN puede cumplir esta función) y que, además, DHCP no proporciona autenticación (de abonado), lo que sugiere que IEEE 802.1X también es necesario para una "solución completa" sin PPPoE. [28] (Este libro supone que PPPoE se aprovecha para otras características de PPP además de la encapsulación, incluido IPCP para la configuración del host y PAP o CHAP para la autenticación).
Existen razones de seguridad para utilizar PPPoE en un entorno de medio compartido (no DSL/ATM), como redes de comunicación por líneas eléctricas , con el fin de crear túneles separados para cada cliente. [29]
PPPoE se usa ampliamente en líneas WAN, incluido FTTx . Muchas puertas de enlace residenciales FTTx proporcionadas por ISP han integrado las funciones de enrutamiento.