Protocolo punto a punto sobre Ethernet

pila de protocolo PPPoE y TCP/IP

Aplicación	FTP	SMTP	HTTP	...	DNS	...
Transporte	TCP				UDP
Internet	IP			IPv6
Acceso a la red	PPP
	PPPoE
	Ethernet

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 de ahí 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". El uso típico de PPPoE implica aprovechar las instalaciones de PPP para autenticar al usuario con un nombre de usuario y una contraseña, principalmente a través del protocolo PAP y, con menos frecuencia, a través de CHAP. Alrededor de 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 al 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 hoy en día.

En el equipo de las instalaciones del cliente, PPPoE se puede implementar en un dispositivo de puerta de enlace residencial unificado que maneja las funciones de enrutamiento de 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 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, desde Windows XP, Linux hasta Mac OS X). Más recientemente, algunas puertas de enlace residenciales basadas en GPON (en lugar de DSL) también usan PPPoE, aunque el estado de PPPoE en el Los estándares GPON son marginales.

PPPoE fue desarrollado por UUNET, Redback Networks (ahora Ericsson) y RouterWare (ahora Wind River Systems) y está disponible como RFC 2516 informativo.

En el mundo de DSL, comúnmente se entendía que PPPoE se ejecutaba sobre ATM (o DSL) como el transporte subyacente, aunque no existe tal limitación en el protocolo PPPoE en sí. Otros escenarios de uso a veces se distinguen añadiendo como sufijo otro transporte subyacente. Por ejemplo, PPPoEoE, cuando el transporte es el propio Ethernet, como es 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 se ha descrito en algunos libros como una "capa 2.5" protocolo, en un sentido rudimentario similar a MPLS porque puede usarse para distinguir diferentes flujos IP que comparten una infraestructura Ethernet, aunque la falta de conmutadores PPPoE que tomen decisiones de enrutamiento basadas en encabezados PPPoE limita la aplicabilidad en ese sentido.

Justificación original

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 niveles domésticos. La tecnología ADSL se había propuesto una década antes. 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 en LEC) enfrentaba una barrera significativa de bajo costo de cantidad. Las estimaciones iniciales para el despliegue de cantidades pequeñas de DSL mostraron costos en el rango de $300 a $500 para un módem DSL y una tarifa de acceso de $300/mes de la empresa de telecomunicaciones, que superaba con creces 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, $ 800- $ 1500 por mes) no era económica, pero que necesitaban más de lo que el acceso telefónico o ISDN podían ofrecer. Si suficientes de estos clientes allanaran el camino, las cantidades reducirían los precios hasta donde el usuario de acceso telefónico para uso doméstico podría estar interesado.

Diferente perfil de uso

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:

• Conectar toda una LAN a Internet;
• Prestación de servicios en una red local accesible desde el extremo de la conexión;
• Acceso simultáneo a múltiples fuentes de datos externas, como una empresa VPN y un propósito general ISP;
• Uso continuo durante todo el día de trabajo, o incluso alrededor del reloj.

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 NAT más acceso telefónico. proporcionó. Se requería un nuevo modelo.

PPPoE se usa principalmente:

• con PPPoE-speaking Servicios DSL de Internet donde un módem de habla PPPoE se conecta al servicio DSL. Aquí tanto ISP como modem-router necesitan hablar PPPoE. (Nota que en este caso, el lado PPPoE-sobre-DSL de las cosas se refiere ocasionalmente como PPPoEoA, para ‘PPPoE sobre ATM’).
• o cuando un PPPoE habla DSL modem está conectado a un router Ethernet de habla PPPoE usando un cable Ethernet.

Tiempo de comercialización: cuanto más simple, mejor

Un problema con la creación de 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 abogaba por las celdas atm basadas en fibra para el escritorio, y L2TP también se estaba gestando, pero no estaba cerca de completarse) llevaría tanto tiempo implementar 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.

Reutilizar pilas de software existentes

PPPoE esperaba fusionar la infraestructura Ethernet generalizada con el omnipresente PPP, lo que permitiría a los proveedores reutilizar su software existente y entregar productos a muy corto plazo. Esencialmente, 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.

Simplifique los requisitos de hardware

Las tecnologías WAN de la competencia (T1, ISDN) requerían un enrutador en las instalaciones del cliente. PPPoE usaba 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 dicho puente es mucho más simple que un enrutador.

RFC informativa

(feminine)

RFC 2516 se publicó inicialmente como un RFC informativo (en lugar de un 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.

Éxito

PPPoE se diseñó inicialmente para proporcionar una pequeña LAN con conexiones independientes individuales 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 llegó. Si bien se puede debatir el éxito en el segundo asunto (algunos se quejan de que 8 bytes por paquete es demasiado), PPPoE claramente logró generar un volumen suficiente para reducir el precio del servicio a lo que pagaría un usuario doméstico.

Casos de uso modernos

Alrededor de 2000, el protocolo PPPoE se usaba (i) para conectar un módem DSL a una computadora o enrutador, reemplazando el método anterior de usar USB, o (ii) el trío de encabezados de protocolo PPP+PPPoE se usaba para conectar un enrutador a un nodo de red, un convertidor de protocolo, un poco más arriba que pertenece al ISP oa 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 PPP es usado.

El segundo caso de uso, donde el trío de protocolos PPPoE se usa en uno o más enlaces de acceso a Internet que alcanzan una profundidad mayor o menor, según el consenso, solo se sigue usando por razones históricas. Sin embargo, debido a que PPP sigue siendo popular entre algunos ISP, ya sea como un protocolo de tunelización, necesario cuando un ISP utiliza un operador de acceso mayorista/revendedor o porque se desean las características de PPP, o ambos.

Como se mencionó anteriormente, extrañamente, los encabezados de Ethernet MAC 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 aparte de agregar más encabezados innecesarios, los llamados inflar. Por ejemplo, en el caso, discutido a continuación, de PPPoEoA, donde no había Ethernet físico, solo ATM, no solo se agregó una capa Ethernet MAC innecesaria de sobrecarga de encabezado, sino también una capa adicional de adaptación de Ethernet para hacer que Ethernet encaje encima de ATM..

En el segundo caso de uso, estos encabezados de protocolo adicionales agregan una gran cantidad de sobrecarga 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 aguas arriba. Puede limitarse a la 'primera milla': un par trenzado de cobre en ADSL o VDSL2/FTTC que involucre módems y nada más, o también puede usarse aguas 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 aguas arriba y termina en un nodo de este tipo operado por un operador mayorista que se convierte al protocolo de tunelización L2TP que tuneliza a los IP POP ('punto de presencia') del ISP.

Etapas

El PPPoE tiene dos etapas distintas:

Descubrimiento de PPPoE

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, es seguro que todas las tramas PPP enviadas por cable 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 alcance el destino deseado.

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 PPPoE Discovery hace exactamente esto. También ayuda a establecer una ID de sesión que se puede usar para un mayor intercambio de paquetes.

Sesión de APP

Una vez que se conoce la dirección MAC del par y se ha establecido una sesión, se iniciará la etapa de sesión.

Did you mean:

PPPoE discovery (PPPoE)

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.

Cliente a servidor: Iniciación (PADI)

PADI significa PPPoE Active Discovery Iniciation.

Si un usuario desea "marcar" a Internet usando 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 a través de 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). Este paquete PADI contiene la dirección MAC de la computadora que lo envía.

Ejemplo de un paquete PADI:

Frame 1 (44 bytes on wire, 44 bytes captured)
Ethernet II, Src: 00:50:da:42:d7:df, Dst: ff:ff:ff:ff:ff:ff:ff
PPP-over-Ethernet Discovery
Versión: 1
Tipo 1
Código Active Discovery Initiation (PADI)
ID de sesión: 0000
Duración de la carga: 24
PPPoE Tags
Tag: Nombre de servicio
Tag: 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 difusión de Ethernet.
El paquete PADI puede ser recibido por más de un DSL-AC. Solo los equipos DSL-AC que pueden servir al "Service-Name" la etiqueta debe responder.

Servidor a cliente: Oferta (PADO)

PADO son las siglas de PPPoE Active Discovery Offer.

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 (por ejemplo, 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 usando el nombre o servicio suministrado.

Este es un ejemplo de un paquete PADO:

Marco 2 (60 bytes en alambre, 60 bytes capturados)
Ethernet II, Src: 00:0e:40:7b:f3:8a, Dst: 00:50:da:42:df
PPP-over-Ethernet Discovery
Versión: 1
Tipo 1
Code Active Discovery Offer (PADO)
ID de sesión: 0000
Duración de la carga: 36
PPPoE Tags
Tag: AC-Name
Datos de cuerda: IpzbrOl
Tag: Host-Uniq
Datos binarios: (16 bytes)

Nombre AC -> Los datos de cadena contienen el nombre del AC, en este caso “Ipzbr001” (el 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).

Cliente a servidor: solicitud (PADR)

PADR significa solicitud de detección activa de PPPoE.

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 emisor del paquete PADO.

Servidor a cliente: sesión-confirmación (PADS)

PADS significa PPPoE Active Discovery Session-confirmation.

El paquete PADR anterior es confirmado por el DSL-AC con un paquete PADS, y se proporciona una ID de sesión con él. La conexión con el DSL-AC para ese POP ahora se ha establecido por completo.

Did you mean:

Either end to other end: termination (PAST)

Did you mean:

PART stands for PPPoE Active Discovery Termination. This packet terminates the connection to the POP. It may be sent either from the user 's computer or from the DSL-AC.

Sobrecarga de protocolo

PPPoE se usa 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 PPPoE a través de ATM (PPPoEoA) sobre la pila de protocolos ADSL. PPPoE sobre ATM tiene la sobrecarga más alta de los métodos populares de entrega de DSL, en comparación con, por ejemplo, PPPoA (RFC 2364).

Did you mean:

Use with DSL – PPPoE over ATM (PPPoE)

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 (que se analiza a continuación), que cancela por completo la sobrecarga adicional de PPPoEoA en algunos casos, (ii) sobrecarga de PPPoEoA + AAL5 que puede hacer que se requiera una celda ATM adicional completa de 53 bytes, y (iii) en el caso de paquetes IP, sobrecarga de PPPoE agregada a los paquetes que están cerca de la longitud máxima ('MRU') puede provocar la fragmentación de IP, lo que también implica las dos primeras consideraciones para los dos fragmentos de IP resultantes. Sin embargo, ignorando la fragmentación de ATM e IP por el momento, los gastos generales del encabezado del protocolo para carga útil de ATM debido a la elección de PPP + PPPoEoA pueden llegar a 44 bytes = 2 bytes (para PPP) + 6 (para PPPoE) + 18 (Ethernet MAC, variable) + 10 (RFC 2684 LLC, variable) + 8 (AAL5 CPCS). Esta sobrecarga es la que se obtiene al usar la opción de cabecera LLC descrita en RFC 2684 para PPPoEoA.

Compare esto con un protocolo mucho más eficiente en encabezados, PPP + PPPoA RFC 2364 VC-MUX sobre ATM+DSL, que tiene una sobrecarga de solo 10 bytes dentro de la carga útil de ATM. (De hecho, simplemente 10 bytes = 2 bytes para PPP + cero para RFC 2364 + 8 (AAL5 CPCS).)

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 Ethernet MAC FCS de 4 bytes, lo que reduce la cifra de 18 bytes anterior a 14, y (ii) mediante el uso de la opción RFC 2684 VC-MUX, cuya contribución de sobrecarga es de solo 2 bytes en comparación con la sobrecarga de 10 bytes de la alternativa LLC. Resulta que esta reducción de gastos generales puede ser una valiosa mejora de la eficiencia. Al utilizar VC-MUX en lugar de LLC, la carga útil de ATM es de 32 bytes (sin Ethernet FCS) o de 36 bytes (con FCS).

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 conforman el paquete de carga útil AAL5. En el caso de LLC, la sobrecarga de carga útil ATM total es 2 + 6 + 18 + 10 + 8 = 44 bytes si está presente Ethernet MAC FCS, o 2 + 6 + 14 + 10 + 8 = 40 bytes sin FCS. En el caso más eficiente de VC-MUX, la sobrecarga de carga útil de ATM es 2 + 6 + 18 + 2 + 8 = 36 bytes (con FCS), o 2 + 6 + 14 + 2 + 8 = 32 bytes (sin SFC).

Sin embargo, la sobrecarga real en términos de la cantidad total de datos de carga útil de cajeros automáticos enviados no es simplemente un valor adicional fijo; puede solo 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 una longitud de 48 bytes.

Un ejemplo: en el caso de un paquete IP de 1500 bytes enviado a través de AAL5/ATM con PPPoEoA y RFC2684-LLC, sin tener en cuenta el relleno de celda final por el momento, uno comienza con 1500 + 2 + 6 + 18 + 10 + 8 (Tráiler AAL5 CPCS) = 1544 bytes si está presente Ethernet FCS, 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 disponible de 32 celdas × 48 bytes por celda = 1536 bytes no es suficiente. Compare esto con el caso de PPP + PPPoA que en 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 proporción de 33:32. 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 de PPPoEoA.

Para algunas longitudes de paquete, la sobrecarga real adicional efectiva de DSL 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 ATM total de 1492 + 44 = 1536 bytes = 32 celdas exactamente, y la sobrecarga en este caso especial no es mayor que si estaban usando el protocolo PPPoA con eficiencia de encabezado, que requeriría 1492 + 2 + 0 + 8 = 1502 bytes de carga útil ATM = 32 celdas también. El caso en el que 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.

Usar PPPoEoA con la opción de encabezado RFC2684 VC-MUX siempre es mucho más eficiente que la opción LLC, ya que la sobrecarga de ATM, como se mencionó anteriormente, es de solo 32 o 36 bytes (dependiendo de si es sin o con Ethernet FCS). opción 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í un ATM completo celúla.

Con paquetes cortos, cuanto mayor sea la sobrecarga del 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 tarda un 50 % más en 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. Como comparación, PPPoA con gastos generales de 10 bytes, por lo que un total de 70 bytes cabe en dos celdas. Por lo tanto, el costo adicional de elegir PPPoE/LLC sobre PPPoA es un 50 % de datos adicionales enviados. Sin embargo, PPPoEoA + VC-MUX estaría bien: con una sobrecarga de 32 o 36 bytes, nuestro paquete IP aún 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, la mejor opción siempre es usar VC-MUX (en lugar de LLC) sin Ethernet FCS, lo que proporciona una sobrecarga de carga útil ATM 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 derrochadores 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 una célula ATM adicional que derrocha.

Sobrecarga en Ethernet

En una LAN Ethernet, la sobrecarga para PPP + PPPoE es fija 2 + 6 = 8 bytes, a menos que se produzca fragmentación de IP.

MTU/MRU

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) incluidos dentro de la carga útil de cada trama Ethernet. Esta sobrecarga añadida puede significar que se impone un límite de longitud máxima reducido (llamado 'MTU' o 'MRU') de 1500 − 8 = 1492 bytes (por ejemplo) Paquetes IP enviados o recibidos, a diferencia del límite de longitud de carga útil de la trama Ethernet habitual de 1500 bytes que se aplica a las redes Ethernet estándar. Algunos dispositivos son compatibles con RFC 4638, que permite negociar el uso de tramas Ethernet no estándar con una carga útil de Ethernet de 1508 bytes, a veces denominadas "tramas gigantes pequeñas", lo que permite una carga útil completa de PPPoE de 1500 bytes. Esta capacidad es ventajosa para muchos usuarios en los casos en que las empresas que reciben paquetes IP han optado (incorrectamente) por bloquear todas las respuestas ICMP para que no salgan de su red, una mala práctica que impide que el descubrimiento de ruta MTU funcione correctamente y que puede causar problemas a los usuarios que acceden a dichas redes. si tienen una MTU de menos de 1500 bytes.

Did you mean:

PPPoE-to-PPPoE converting ADSL modem

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 PPPoEoA en esta cadena de protocolo. Este es un diseño de protocolo eficiente óptimo para un módem ADSL separado conectado a un enrutador por 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 sola 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 manera.

Al transmitir paquetes destinados a Internet, el enrutador Ethernet que habla PPPoE envía tramas Ethernet al módem DSL (que también 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.

DSL Arquitectura de acceso a Internet

PC o Gateway		DSL modem		DSLAM		Servidor de acceso remoto		(ISP)
(IP)								(IP)
Ethernet	PPP					PPP	PPP	PPP
	PPPoE	PPPoE	PPPoA			PPPoA	L2TP	L2TP
	Ethernet	Ethernet	AAL5	AAL5	columna vertebral	columna vertebral	IP	IP
			ATM	ATM
			DSL	DSL

En el diagrama, el área que se muestra como "red troncal" también podría ser un cajero automático 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.

Extravagancias

Dado que la conexión punto a punto establecida tiene una MTU más baja que la de Ethernet estándar (generalmente 1492 frente a 1500 de Ethernet), a veces puede causar problemas cuando Path MTU Discovery es derrotado por cortafuegos mal configurados. Aunque las MTU más altas se están volviendo más comunes en los proveedores' redes, por lo general, la solución alternativa es usar TCP MSS (Tamaño máximo de segmento) "sujeción" o 'reescribir', 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 fijación de TCP MSS resuelve el problema de MTU para TCP, otros protocolos como ICMP y UDP aún pueden verse afectados.

RFC 4638 permite que los dispositivos PPPoE negocien una MTU superior a 1492 si la capa Ethernet subyacente es capaz de tramas gigantes.

Algunos proveedores (Cisco y Juniper, 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 con puente 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. (PPPoEoA no es lo mismo que el protocolo punto a punto sobre ATM (PPPoA), que no usa 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 802.1q VLAN en lugar de ATM. Este método de encapsulación generalmente se encuentra en entornos de Metro Ethernet o Ethernet de multiplexor de acceso a línea de suscriptor digital (DSLAM). El modelo de implementación común es que este método de encapsulación se encuentra típicamente en edificios u hoteles de múltiples inquilinos. Al entregar Ethernet al suscriptor, el ancho de banda disponible es mucho más abundante y se incrementa la facilidad de la entrega de servicios adicionales."

Es posible encontrar módems DSL, como 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).

Usos post-DSL y algunas alternativas en estos contextos

ZTE ha patentado un determinado método de uso de PPPoE junto con GPON (que implica la creación de una VLAN a través de OMCI).

Se informa que PPPoE sobre GPON es utilizado por proveedores de servicios minoristas como Internode de la Red Nacional de Banda Ancha de Australia, Orange de Francia, Filipinas' Globe Telecom y Aruba FTTH de Italia en redes GPON públicas 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 suscriptores y administrar su IP direcciones, 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 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 del protocolo en GPON siempre es IPoE."

El estándar 10G-PON (XG-PON) (G.987) proporciona autenticación mutua 802.1X de la ONU y la OLT, además del método OMCI transferido desde G.984. 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 husmea en los mensajes RADIUS encapsulados en EAP en este escenario y determina si la autenticación fue exitosa o no). agregue 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.

El Foro de Banda Ancha TR-200 "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.&# 34;

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 alguna encapsulación (aunque los puentes VLAN pueden cumplir esta función) y que, además, DHCP no proporciona autenticación (suscriptor), lo que sugiere que IEEE 802.1X también es necesario para una "solución completa" sin PPPoE. (Este libro asume que PPPoE se aprovecha para otras funciones de PPP además de la encapsulación, incluido IPCP para la configuración del host y PAP o CHAP para la autenticación).

Hay razones de seguridad para usar PPPoE en un entorno de medio compartido (no DSL/ATM), como redes de comunicación de línea eléctrica, para crear túneles separados para cada cliente.

PPPoE se usa ampliamente en líneas WAN, incluido FTTx. Muchas puertas de enlace residenciales FTTx proporcionadas por ISP tienen funciones de enrutamiento integradas.