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 de DSL como la solución para tunelizar paquetes a través de la conexión DSL a la red IP del ISP , y desde allí al resto de Internet . Un libro de 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 facilidades PPP para autenticar al usuario con un nombre de usuario y contraseña, a través del protocolo PAP o mediante CHAP . PAP fue dominante en 2007, pero los proveedores de servicios han estado haciendo la transición al CHAP más seguro, porque PAP es un protocolo de texto sin formato. [2] Alrededor del año 2000, PPPoE también comenzó a convertirse en un método de reemplazo para comunicarse con un módem conectado a una computadora o enrutador a través de una LAN Ethernet, reemplazando el método anterior, que había sido USB . Este caso de uso, que consiste en 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 funciones de enrutamiento IP y módem DSL o, en el caso de un módem DSL simple (sin soporte de enrutamiento), PPPoE se puede manejar detrás de él en un enrutador solo Ethernet separado o incluso directamente en la computadora de un usuario. (El soporte para PPPoE está presente en la mayoría de los sistemas operativos, que van 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 basadas en DSL) también usan PPPoE, aunque el estado de PPPoE en los estándares GPON es marginal aunque se menciona en la recomendación ITU-T G.984.1 " Redes ópticas pasivas con capacidad Gigabit (GPON): características generales" .
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, generalmente se entiende que PPP se ejecuta sobre ATM (como PPPoA), con ATM como protocolo de capa 2 subyacente y una versión de DSL como protocolo de capa 1, aunque no existe tal limitación en el protocolo PPP en sí.
En ocasiones, otros escenarios de uso se distinguen añadiendo como sufijo otro protocolo 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 tiene una encapsulación diferente del protocolo PPP).
PPPoE ha sido descrito en algunos libros como un protocolo de " capa 2.5 ", [2] [7] en un sentido rudimentario similar a MPLS porque se puede utilizar para distinguir diferentes flujos de IP que comparten una infraestructura Ethernet, aunque la falta de conmutadores PPPoE que tomen decisiones de enrutamiento basadas en encabezados PPPoE limita la aplicabilidad a ese respecto. [7]
A fines de 1998, el modelo de servicio DSL aún no había alcanzado la gran escala que haría bajar los precios a los niveles domésticos. La tecnología ADSL se había propuesto una década antes. [8] Los posibles proveedores de equipos y operadores reconocieron que la banda ancha, como el módem de cable o DSL, eventualmente reemplazaría el servicio de acceso telefónico , pero el hardware (tanto en las instalaciones del cliente como en LEC ) enfrentaba una importante barrera de costo de baja cantidad . Las estimaciones iniciales para la implementación de DSL en pequeñas cantidades mostraban costos en el rango de US$300-500 (US$561-935 en 2023) para un módem DSL y una tarifa de acceso de US$300/mes de la compañía de telecomunicaciones, [ cita requerida ] que estaba muy por encima de lo que pagaría un usuario doméstico. Por lo tanto, el enfoque inicial estaba en los clientes de pequeñas empresas y hogares para quienes una ~ La línea T1 de 1,5 Mbit/s (que en aquel momento costaba entre 800 y 1.500 dólares al mes) no era económica, pero ¿quién necesitaba más de lo que podía ofrecer la conexión por dial-up o RDSI ? Si un número suficiente de estos clientes abría el camino, la cantidad haría bajar los precios hasta el nivel que podría interesar al usuario de dial-up doméstico.
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 un ordenador a un ISP, ni siquiera al modelo de muchos a uno que proporcionaba NAT más el acceso telefónico. Se necesitaba un nuevo modelo.
PPPoE se utiliza principalmente:
Un problema con la creación de un protocolo completamente nuevo para cubrir estas necesidades era el tiempo. El equipo estaba disponible de inmediato, al igual que el servicio, y el desarrollo de una pila de protocolos completamente nueva ( en ese momento, Microsoft estaba promoviendo el uso de celdas ATM basadas en fibra hasta el escritorio [9] y L2TP también estaba en desarrollo, pero no estaba cerca de completarse) llevaría tanto tiempo implementarlo que la ventana de 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 y a un menor costo.
PPPoE esperaba fusionar la infraestructura Ethernet generalizada con el ubicuo PPP, lo que permitiría a los proveedores reutilizar su software existente y entregar productos en un plazo muy cercano. Básicamente, todos los sistemas operativos de la época tenían una pila PPP, y el diseño de PPPoE permitía un envoltorio/compensación simple para permitir la encapsulación de tramas PPP dentro de tramas Ethernet. [ cita requerida ]
Las tecnologías WAN competidoras (T1, ISDN) requerían un enrutador en las instalaciones del cliente. PPPoE utilizaba un tipo de trama Ethernet diferente, lo que permitía 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 varios órdenes de magnitud más sencilla que la de un enrutador.
El RFC 2516 se publicó inicialmente como un RFC informativo (en lugar de uno de seguimiento de estándares ) por la misma razón: el período de adopción de un RFC de seguimiento de estándares era prohibitivamente largo.
PPPoE fue diseñado inicialmente para proporcionar una pequeña red local con conexiones individuales e independientes a Internet en general, pero también para que el protocolo en sí fuera lo suficientemente liviano como para no afectar el mercado de uso doméstico esperado cuando finalmente llegara. Si bien el éxito en el segundo aspecto 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 utilizó (i) para conectar un módem DSL a una computadora o enrutador, desplazando el método anterior de usar USB , o (ii) el trío de encabezados de protocolo PPP+PPPoE se utilizó para conectar un enrutador a un nodo de red, un convertidor de protocolo, algo más arriba, perteneciente 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 denominado "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 utiliza PPP.
El segundo caso de uso, en el que el trío de protocolos PPPoE se utiliza en uno o más enlaces de acceso a Internet que llegan a una mayor o menor profundidad, se sigue utilizando, según el consenso, solo por razones históricas. Sin embargo, PPP sigue siendo popular entre algunos ISP, ya sea como protocolo de tunelización, necesario cuando un ISP utiliza un proveedor de acceso mayorista/revendedor o porque se desean las características de PPP, o ambas cosas.
Como se mencionó anteriormente, curiosamente, los encabezados MAC de Ethernet a veces se encuentran en uso con encabezados PPPoE incluso cuando el protocolo Ethernet no está en uso, no está físicamente presente en una red Ethernet. Esto parece no tener ningún propósito más allá de agregar más sobrecarga de encabezado innecesaria, lo que se denomina 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 sobrecarga de encabezado, sino también una capa de adaptación de Ethernet adicional para hacer que Ethernet se ajuste a ATM.
En el segundo caso de uso, estos encabezados de protocolo adicionales agregan una cantidad importante de hinchazón y, por lo tanto, dañan el rendimiento en una pequeña cantidad.
En el segundo caso de uso, el uso de PPP+PPPoE+Ethernet MAC se extiende a una distancia variable en sentido ascendente. Puede limitarse a la " primera milla ": un par trenzado de cobre en ADSL o VDSL2 / FTTC que involucre módems y no más allá, o también puede usarse más en sentido ascendente 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 que sin duda será un convertidor de protocolo de algún tipo. En un caso de ejemplo, PPPoE se extiende en sentido ascendente hasta un nodo operado por un operador mayorista y termina en él, que convierte al protocolo de tunelización L2TP que realiza un túnel hacia los POP de 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 de un circuito virtual ATM que ya se ha establecido durante la conexión telefónica, todas las tramas PPP enviadas por el cable llegan con seguridad 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 la trama 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 que puedan codificarse en estos paquetes de control. La etapa de descubrimiento PPPoE hace exactamente esto. También ayuda a establecer un ID de sesión que se puede utilizar para un mayor intercambio de paquetes y también se utiliza para indicar la finalización de la sesión.
Los paquetes de descubrimiento PPPoE se transportan en tramas Ethernet con EtherType establecido en 0x8863.
Una vez que se conoce la dirección MAC del par y se ha establecido una sesión, comenzará la etapa de sesión. En esta etapa, se encapsulan fragmentos de datos PPP en paquetes PPPoE y se envían al otro par. Los primeros paquetes de sesión negociarán la sesión PPP como de costumbre y, a partir de entonces, la mayoría de los paquetes de sesión contendrán fragmentos de datos PPP.
La encapsulación se realiza anteponiendo los fragmentos PPP con el encabezado PPPoE de 6 bytes y transportándolos en tramas Ethernet con EtherType establecido en 0x8864.
Aunque el PPP tradicional es un protocolo punto a punto , 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 el equipo 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 PPPoE Active Discovery Initiation. [10]
Si un usuario desea conectarse a Internet mediante DSL, 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 solo es posible mediante direcciones MAC . Como la computadora 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:ff). Este paquete PADI contiene la dirección MAC de la computadora que lo envía.
Ejemplo de un paquete PADI:
Cuadro 1 (44 bytes en el 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. (=origen) 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. Solo el equipo DSL-AC que pueda servir la etiqueta "Service-Name" debe responder.
PADO significa PPPoE Active Discovery Offer. [10]
Una vez que el ordenador del usuario ha enviado el paquete PADI, el DSL-AC responde con un paquete PADO, utilizando la dirección MAC suministrada en el PADI. El paquete PADO contiene la dirección MAC del DSL-AC, su nombre (por ejemplo, LEIX11-erx para el DSL-AC de T-Com en Leipzig ) y el nombre del servicio. Si más de un DSL-AC de POP responde con un paquete PADO, el ordenador del usuario selecciona el DSL-AC para un POP en particular utilizando el nombre o servicio suministrado.
A continuación se muestra un ejemplo de un paquete PADO:
Cuadro 2 (60 bytes en el 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 de código activo (PADO) ID de sesión: 0000 Longitud de carga útil: 36Etiquetas PPPoE Etiqueta: AC-Nombre Datos de la cadena: lpzbr001 Etiqueta: Host-Uniq Datos binarios: (16 bytes)
AC-Name -> String data contiene el nombre del AC, en este caso “lpzbr001” (el DSL-AC Arcor 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]
El ordenador del usuario envía un paquete PADR al DSL-AC tras 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 junto con él se envía un identificador de sesión. La conexión con el DSL-AC para ese POP ya está completamente establecida.
PADT significa PPPoE Active Discovery Termination. [10] Este paquete finaliza la conexión al POP. Puede enviarse desde la computadora del usuario o desde el DSL-AC.
PPPoE se utiliza para conectar un PC o un enrutador a un módem a través de un enlace Ethernet y también se puede utilizar en el acceso a Internet a través de DSL en una línea telefónica en la pila de protocolos PPPoE sobre ATM (PPPoEoA) sobre ADSL . PPPoE sobre ATM tiene la mayor sobrecarga 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 celdas ATM (discutido a continuación), que cancela completamente la sobrecarga adicional de PPPoEoA en algunos casos, (ii) la sobrecarga de PPPoEoA + AAL5 que puede causar que se requiera una celda ATM adicional de 53 bytes, y (iii) en el caso de paquetes IP, la sobrecarga de PPPoE agregada a paquetes que están cerca de la longitud máxima ( " MRU " ) puede causar fragmentación de IP , que también involucra las dos primeras consideraciones para ambos fragmentos de IP resultantes. [15] Sin embargo, ignorando por el momento la fragmentación de ATM e IP, 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 (MAC de Ethernet, 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]
Compárese esto con un protocolo mucho más eficiente en cuanto a encabezados, PPP + PPPoA RFC 2364 VC-MUX sobre ATM+DSL, que tiene una sobrecarga de apenas 10 bytes dentro de la carga útil ATM. (De hecho, simplemente 10 bytes = 2 bytes para PPP + cero para RFC 2364 + 8 (AAL5 CPCS).) [12] [14]
Esta cifra de 44 bytes de sobrecarga de carga útil AAL5 se puede reducir de dos maneras: (i) eligiendo la opción RFC 2684 de descartar el FCS MAC Ethernet de 4 bytes, lo que reduce la cifra de 18 bytes anterior a 14, y (ii) utilizando la opción VC-MUX RFC 2684, 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 sobrecarga puede ser una valiosa mejora de la eficiencia. Utilizando VC-MUX en lugar de LLC, la sobrecarga de carga útil ATM es de 32 bytes (sin FCS Ethernet) o de 36 bytes (con FCS). [11] [13]
ATM AAL5 requiere que siempre esté presente un tráiler 'CPCS' de 8 bytes de longitud al final de la celda final ('justificado 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 la carga útil ATM es 2 + 6 + 18 + 10 + 8 = 44 bytes si está presente el FCS MAC Ethernet, o 2 + 6 + 14 + 10 + 8 = 40 bytes sin FCS. En el caso VC-MUX más eficiente, la sobrecarga de la carga útil ATM es 2 + 6 + 18 + 2 + 8 = 36 bytes (con FCS), o 2 + 6 + 14 + 2 + 8 = 32 bytes (sin FCS).
Sin embargo, la sobrecarga real en términos de la cantidad total de datos de carga útil ATM enviados no es simplemente un valor adicional fijo: solo puede ser cero o 48 bytes (dejando de lado el escenario (iii) mencionado anteriormente, la 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. La última o las dos últimas celdas ATM contienen bytes de relleno según sea necesario para garantizar que la carga útil de cada celda tenga una longitud de 48 bytes. [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 de celda final, se comienza con 1500 + 2 + 6 + 18 + 10 + 8 (AAL5 CPCS trailer) = 1544 bytes si está presente el FCS Ethernet, o bien + 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. Comparemos esto con el caso de PPP + PPPoA, en el que 1500 + 2 (PPP) + 0 (PPPoA: RFC 2364 VC-MUX) + 8 (CPCS trailer) = 1510 bytes caben en 32 celdas. Por lo tanto, 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 relación de 33:32. [11] [12] [13] Por lo tanto, para paquetes de 1500 bytes, PPPoEoA con LLC es aproximadamente un 3,125 % más lento que PPPoA o las opciones óptimas 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 particular. Por ejemplo, un paquete de 1492 bytes de longitud enviado con PPP + PPPoEoA utilizando RFC2684-LLC más FCS nos da una carga útil ATM total de 1492 + 44 = 1536 bytes = 32 celdas exactamente, y la sobrecarga en este caso especial no es mayor que si estuviéramos utilizando el protocolo PPPoA eficiente en encabezado, que requeriría 1492 + 2 + 0 + 8 = 1502 bytes de carga útil ATM = 32 celdas también. [11] [13] El caso donde la longitud del paquete es 1492 representa la eficiencia óptima para PPPoEoA con RFC2684-LLC en términos de proporción, a menos que se permitan paquetes aún más largos.
El uso de PPPoEoA con la opción de encabezado VC-MUX RFC2684 es siempre mucho más eficiente que la opción LLC, ya que la sobrecarga ATM, como se mencionó anteriormente, es de solo 32 o 36 bytes (dependiendo de si esto es sin o con la opción Ethernet FCS en PPPoEoA) de modo que un paquete de 1500 bytes de longitud incluyendo toda la sobrecarga de PPP + PPPoEoA usando VC-MUX equivale a una carga útil ATM total de 1500 + 36 = 1536 bytes si el FCS está presente = 32 celdas ATM exactamente, ahorrando así una celda ATM entera. [11] [13]
En el caso de los paquetes cortos, cuanto más largos sean los encabezados, mayor será la probabilidad de generar una celda ATM adicional. El peor de los casos podría ser el envío de 3 celdas ATM en lugar de dos debido a un encabezado de 44 bytes en comparación con uno de 10 bytes, por lo que se necesitaría 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 un encabezado de 40 o 44 bytes para PPPoEoA + LLC, esto requiere tres cargas útiles de celdas ATM de 48 bytes. A modo de comparación, PPPoA con encabezados de 10 bytes, por lo que 70 bytes en total caben en dos celdas. Por lo tanto, el costo adicional de elegir PPPoE/LLC en lugar de PPPoA es un 50 % de datos adicionales enviados. Sin embargo, PPPoEoA + VC-MUX estaría bien: con un encabezado 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 ATM es elegir PPPoA (RFC2364) VC-MUX. Sin embargo, si se requiere PPPoEoA, la mejor opción es siempre utilizar VC-MUX (en lugar de LLC) sin FCS Ethernet, lo que da una sobrecarga de carga útil ATM de 32 bytes = 2 bytes (para PPP) + 6 (para PPPoE) + 14 (MAC Ethernet, sin FCS) + 2 (VC-MUX RFC 2684) + 8 (AAL5 CPCS trailer).
Lamentablemente, algunos servicios DSL requieren el uso de encabezados LLC innecesarios 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 por ejemplo la imposición de 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 ninguna celda ATM innecesaria adicional.
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 utiliza PPPoE envía o recibe tramas Ethernet que contienen una carga útil PPP + PPPoE a través del enlace Ethernet a un enrutador (o una PC que utiliza PPPoE), PPP + PPPoE aporta una sobrecarga adicional de 8 bytes = 2 (PPP) + 6 (PPPoE) incluidos en la carga útil de cada trama Ethernet. Esta sobrecarga adicional puede significar que se imponga un límite de longitud máxima reducida (denominado " MTU " o " MRU " ) de 1500 − 8 = 1492 bytes en (por ejemplo) los paquetes IP enviados o recibidos, en contraposición al límite habitual de longitud de carga útil de trama Ethernet de 1500 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 llamadas " tramas jumbo baby ", lo que permite una carga útil PPPoE completa de 1500 bytes. Esta capacidad es ventajosa para muchos usuarios en casos donde las compañías que reciben paquetes IP han elegido (incorrectamente) bloquear todas las respuestas ICMP que salen de su red, una mala práctica que impide que el descubrimiento de la MTU de la 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 conversor de protocolo PPPoE a PPPoA y el proveedor de servicios ofrece un servicio PPPoA y no entiende PPPoE. No hay PPPoEoA en esta cadena de protocolos. Este es un diseño óptimamente eficiente en cuanto a protocolos para un módem ADSL independiente conectado a un enrutador por Ethernet.
En esta tecnología alternativa, PPPoE es simplemente un medio para conectar módems DSL a un enrutador que sólo funciona con Ethernet (o a una sola PC host). En este caso, 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 manera.
Al transmitir paquetes destinados a Internet, el enrutador Ethernet que admite PPPoE envía tramas Ethernet al módem DSL (que también admite PPPoE). El módem extrae tramas PPP de las tramas PPPoE recibidas y las envía al DSLAM encapsulándolas de acuerdo con RFC 2364 (PPPoA), convirtiendo así PPPoE en PPPoA.
En el diagrama, el área que se muestra como "columna vertebral" 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 la 1500 de Ethernet), a veces puede causar problemas cuando Path MTU Discovery se ve anulado por cortafuegos mal configurados . Aunque las MTU más altas se están volviendo más comunes en las redes de los proveedores, normalmente la solución alternativa es utilizar la "reescritura" o "sujeción" de TCP MSS (tamaño máximo de segmento), mediante la 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 la MTU para TCP, otros protocolos como ICMP y UDP aún pueden verse afectados.
RFC 4638 permite que los dispositivos PPPoE negocien una MTU mayor que 1492 si la capa Ethernet subyacente es capaz de manejar 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 , para distinguirlo de PPPoEoA (PPPoE sobre ATM), que es PPPoE que se ejecuta sobre un circuito virtual ATM utilizando RFC 2684 y encapsulación SNAP de PPPoE. [ cita requerida ] (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 en la que el protocolo de transporte de capa 2 es ahora Ethernet o VLAN 802.1q en lugar de ATM. Este método de encapsulación se encuentra generalmente en entornos Metro Ethernet o Ethernet Digital Subscriber Line Access Multiplexer (DSLAM). El modelo de implementación común es que este método de encapsulación se encuentra típicamente en edificios con múltiples inquilinos u hoteles. Al entregar Ethernet al suscriptor, el ancho de banda disponible es mucho más abundante y se incrementa la facilidad de entrega de servicios adicionales". [16]
Es posible encontrar módems DSL, como el Draytek Vigor 120, donde PPPoE está confinado 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 método determinado para utilizar PPPoE junto con GPON (que implica la creación de una VLAN a través de OMCI) . [18]
Se informa que 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] utilizan PPPoE sobre GPON en redes GPON públicas OpenFiber .
RFC 6934, "Aplicabilidad del mecanismo de control de nodo de acceso a redes de banda ancha basadas en PON", que defiende el uso del protocolo de control de nodo de acceso en las PON para, entre otras cosas, autenticar el acceso de los suscriptores y gestionar sus direcciones IP, y cuyo primer autor es un empleado de Verizon, excluye PPPoE como encapsulación aceptable para GPON: "La encapsulación de protocolo en BPON se basa en la 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 de protocolo en GPON es siempre IPoE". [23]
El estándar 10G-PON (XG-PON) ( G.987 ) proporciona autenticación mutua 802.1X de la ONU y OLT, además del método OMCI transferido desde 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 en EAP en este escenario y determina si la autenticación fue exitosa o no). [25] Hay un soporte mínimo para PPPoE especificado en los estándares OMCI, pero solo en términos de que la ONU pueda filtrar y agregar etiquetas VLAN para el tráfico en función de su encapsulación (y otros parámetros), que incluye PPPoE entre los protocolos que la ONU debe poder discernir. [26]
El documento TR-200 del Broadband Forum "Uso de EPON en el contexto de TR-101" (2011), que también se refiere a 10G-EPON , dice: "La OLT y la ONU de múltiples suscriptores DEBEN poder realizar la función de agente intermedio PPPoE, 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 utilizar 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 cierta encapsulación (aunque los puentes VLAN pueden cumplir esta función) y que, además, DHCP no proporciona autenticación (de suscriptor), lo que sugiere que también se necesita IEEE 802.1X para una "solución completa" sin PPPoE. [28] (Este libro asume 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 utiliza ampliamente en líneas WAN, incluidas FTTx . Muchas puertas de enlace residenciales FTTx proporcionadas por ISP tienen funciones de enrutamiento integradas.