Resumo

  • A MRU informa uma capacidade de recepção; não exige que o outro lado preencha todo o espaço disponível. Um teto anunciado e o tamanho efetivamente usado são medidas distintas.
  • O PPPoE tradicional reservava seis bytes para seu cabeçalho e dois para o identificador de protocolo PPP, deixando 1492 dentro de uma carga Ethernet de 1500 bytes.
  • A extensão de 2006 permitiu declarar suporte a cargas maiores, negociar dentro dos limites locais e restringir a sessão quando uma tentativa grande falhava, mas uma de 1492 recebia resposta.

A diferença entre espaço e obrigação

Uma extremidade de PPP pode dizer que aceita pacotes maiores sem exigir que todos os pacotes seguintes tenham aquele tamanho. Essa distinção simples é essencial para entender a extensão de PPPoE que surgiu em 2006. A capacidade é um limite, não um volume prometido de tráfego.

O RFC 1661, publicado em julho de 1994, define a Maximum-Receive-Unit, ou MRU, para os campos de informação e preenchimento. O campo de protocolo e o enquadramento externo não entram nessa conta. O valor padrão do PPP comum é 1500 bytes, mas isso não elimina restrições próprias de uma encapsulação específica.

Quando se anuncia uma MRU, comunica-se o que pode ser recebido ou pede-se uma dimensão menor. O outro lado não fica obrigado a produzir pacotes cheios. Logo, uma captura com pacotes pequenos não demonstra, por si só, que a negociação de uma capacidade maior falhou. Tampouco uma tela com um número alto demonstra que pacotes daquele tamanho atravessaram a rede.

O RFC 4638, de setembro de 2006, colocou mais uma camada nessa distinção. Antes de negociar a MRU pelo LCP, as extremidades de PPPoE poderiam anunciar que entendiam uma extensão para ultrapassar o limite tradicional. Entendimento comum, escolha local e transporte real continuavam sendo questões diferentes.

Oito bytes que continuaram ocupando espaço

O limite original vinha do RFC 2516, de fevereiro de 1999. Uma carga útil Ethernet de 1500 bytes precisava acomodar seis bytes de cabeçalho PPPoE e dois de PPP Protocol-ID. Restavam 1492 bytes para a carga PPP.

Os 1500 bytes dessa conta não são o quadro inteiro no meio físico. Cabeçalho Ethernet, verificação, preâmbulo e eventuais campos adicionais pertencem a outras partes da contagem. Tratar uma indicação de tamanho total como se fosse o limite de carga útil produz conclusões erradas antes mesmo de examinar os equipamentos.

A solução de 2006 dependia de sistemas Ethernet capazes de transportar cargas maiores. Para manter 1500 bytes de carga PPP sob a mesma contabilidade de seis mais dois, seriam necessários 1508 bytes de carga Ethernet. Não houve compressão milagrosa nem dispensa dos oito bytes.

Isso também não transforma 1508 em uma receita universal para qualquer interface. A forma como um equipamento contabiliza quadros e etiquetas precisa ser compatível com o que se está medindo. A especificação oferece uma relação entre grandezas, não um comando pronto para todos os fabricantes.

O computador deixou de negociar a fronteira

O motivo da extensão não era apenas aproveitar pacotes maiores. O RFC 4638 descreve uma mudança no local onde começava a sessão. No arranjo anterior, o computador iniciava PPPoE através do acesso. A limitação a 1492 era, segundo o documento, normalmente aceitável nesse modelo.

Com o gateway residencial, a máquina da rede local enviava IP sobre Ethernet para um equipamento que, por sua vez, iniciava PPPoE. O gateway recebia do lado interno pacotes IP de até 1500 bytes e encontrava no lado de acesso a fronteira de 1492.

A encapsulação não tinha aumentado. O ponto de responsabilidade havia mudado. O produtor do pacote já não participava diretamente da negociação PPP que limitava o próximo trecho. Cabia ao gateway reconciliar expectativas que antes estavam mais próximas do mesmo endpoint.

O texto de 2006 também trata de migrações de PPPoA para PPPoE e relata equipamentos de cliente PPPoA então instalados que não suportavam o ajuste para 1492. A afirmação pertence àquele contexto histórico; não é um censo atual, nem uma propriedade universal de qualquer equipamento PPPoA.

Além disso, ATM não oferecia capacidade sem limites. Pelo RFC 2364, de julho de 1998, a MRU de PPP sobre AAL5 não podia exceder a CPCS-SDU máxima do contrato de tráfego da conexão virtual na direção correspondente. A migração trocava um conjunto de condições inferiores por outro.

Descobrir o par não encerra o trabalho

PPPoE tem uma etapa de descoberta e outra de sessão PPP. O cliente transmite PADI, recebe ofertas PADO, escolhe um concentrador e envia PADR; PADS confirma a sessão. Endereços Ethernet e identificador de sessão permitem associar o tráfego posterior aos participantes.

Essa sequência não conclui todas as fases de PPP. A configuração de enlace, a autenticação quando aplicável e a preparação da camada de rede têm seus próprios procedimentos. Uma descoberta bem-sucedida também pode usar mensagens pequenas demais para expor uma limitação a quadros maiores.

É nessa descoberta que entra PPP-Max-Payload. O cliente que pretende ultrapassar 1492 deve inserir a etiqueta tanto em PADI quanto em PADR. O servidor que entende a extensão e recebe a etiqueta deve devolvê-la em PADO e PADS.

O tipo é 0x0120, equivalente a 288 em decimal. O valor ocupa dois bytes e indica, em bytes, a maior carga PPP que o cliente suporta para enviar e receber. Não se deve confundir o identificador 288 com o tamanho anunciado, nem tratar os dois bytes de valor como uma sobrecarga nova em cada pacote da sessão.

Equipamentos antigos podem ignorar tipos de etiqueta desconhecidos. Por isso, a ausência de uma indicação dos dois lados conserva o teto de 1492. Continuar a descoberta não significa aceitar silenciosamente a extensão. Um anúncio de 1492 ou menos tampouco abre a possibilidade de usar mais.

A devolução não é o resultado final

Ao devolver a etiqueta, o servidor repete a informação do cliente. Ele não precisa substituir ali o número por seu próprio máximo efetivo. A restrição local entra depois, na preparação da negociação de MRU.

O procedimento do RFC 4638 começa com 1492. Quando a etiqueta existe e anuncia um número maior, o teto passa a ser o menor entre esse número e a MTU da interface menos oito. O LCP negocia então dentro desse espaço, segundo as regras normais de PPP.

Assim, um valor alto observado em PADO e uma MRU posterior menor podem ser perfeitamente coerentes. O primeiro confirma uma linguagem compartilhada; a segunda reflete a escolha possível naquele enlace. São registros de decisões distintas.

O documento oferece outro limite importante: uma etiqueta maior que 1500 não produz sozinha uma MRU efetiva acima de 1500. Se as condições da extensão forem satisfeitas, mas não houver negociação de uma MRU maior, permanece o padrão normal de PPP. Esse raciocínio não autoriza usar 1500 em uma sessão tradicional que continuou limitada a 1492.

O caminho intermediário não respondeu à proposta

Uma ponte Ethernet no meio do acesso pode encaminhar as pequenas mensagens de descoberta e controle sem conseguir encaminhar os maiores quadros pretendidos. Ela não participou da negociação entre as extremidades.

O RFC 4638 prevê que, depois de abrir a sessão e negociar uma MRU superior a 1492, o emissor deva ter a opção de enviar uma ou mais LCP Echo-Requests no tamanho da MRU. Se não houver respostas, ele pode repetir a tentativa com 1492 bytes. Recebendo respostas nessa dimensão menor, não pode enviar acima de 1492 durante aquela sessão.

A função deveria estar ativa por padrão, ser configurável e poder ser desabilitada quando o conhecimento prévio da rede justificasse a decisão. O texto não exige uma sondagem idêntica em todas as sessões, nem determina um número universal de repetições ou um intervalo que se possa inventar.

O resultado tem alcance limitado. Uma falha grande seguida de sucesso pequeno orienta o comportamento da sessão; não localiza automaticamente o equipamento restritivo. Falha nos dois tamanhos não prova funcionamento em 1492. Uma resposta pequena não demonstra passagem de uma carga maior.

O RFC 1661 permite Echo-Request e Echo-Reply no estado LCP Opened e relaciona a resposta pelo Identifier. Isso não garante que toda resposta tenha exatamente o tamanho da requisição. Uma troca bem-sucedida não certifica permanentemente o transporte máximo nas duas direções. O registro precisa guardar os tamanhos reais, não apenas o rótulo de sucesso.

Um teste de acesso não mede toda a Internet

O RFC 1191, de novembro de 1990, descreveu a descoberta da MTU de caminho em IPv4. A origem usa o bit que proíbe fragmentação e reduz sua estimativa quando recebe o ICMP correspondente de um roteador incapaz de encaminhar sem fragmentar.

Nessa condição, o roteador descarta e sinaliza. Portanto, não é correto afirmar que todo pacote grande demais será simplesmente fragmentado. A política expressa pelo bit DF muda o resultado.

Já a comparação de tamanhos de PPPoE trata da sessão e do transporte Ethernet intermediário. Ela não substitui a descoberta de limites mais adiante, até um destino remoto. O acesso pode aceitar o tamanho desejado e ainda existir outra restrição no caminho roteado.

Manter as duas perguntas separadas evita exagerar o valor de uma medição local. O teste de sessão é útil pelo que observa, não por uma suposta autoridade sobre todo o percurso do pacote.

O registro coordenou o significado

RFC 4638 é um documento Informational, não um Internet Standard. A nota do IESG nele incluída chama atenção para o contexto de padronização de Ethernet acima de 1500 em 2006. Não se deve reapresentar aquela advertência como descrição das normas em 2026.

Em junho de 2007, o RFC 4937 organizou o registro dos tipos de etiqueta PPPoE na IANA e relacionou PPP-Max-Payload ao valor decimal 288. O registro de parâmetros PPPoE da IANA consultado mantém a associação.

Um código comum permite que implementações independentes reconheçam a mesma informação. Não informa quando uma rede ganhou capacidade, nem demonstra adoção universal. Encapsulação em 1999, extensão em 2006 e organização do registro em 2007 são acontecimentos diferentes.

A contribuição duradoura foi tornar verificável a sequência: declarar uma possibilidade, negociar sob condições locais e aceitar que a observação operacional ainda possa restringi-la. Capacidade anunciada não se tornou capacidade entregue por força da declaração. Os oito bytes continuaram precisando de lugar.