Resumo

  • A RFC 2516 limitou o MTU do PPP no PPPoE a 1.492 bytes: seis bytes do cabeçalho PPPoE e dois do PPP Protocol ID ocupavam o restante do payload Ethernet de 1.500 bytes.
  • A RFC 4638 transformou um MTU/MRU maior em uma capacidade negociada opcional. Cliente, concentrador de acesso, configuração da interface e segmentos Ethernet intermediários precisavam aceitar o tamanho para a sessão transportar os oito bytes adicionais.

O limite era uma conta de subtração

Um payload Ethernet de 1.500 bytes parece suficiente para um pacote de Internet do mesmo tamanho. O PPPoE consumia oito bytes antes de o pacote chegar ao cabo: seis no próprio cabeçalho e dois no identificador de protocolo PPP. Em fevereiro de 1999, a RFC 2516 fixou o MTU PPP em 1.492 bytes em um segmento Ethernet padrão.

A subtração era simples. A escolha mais difícil era outra: por que manter o PPP quando o equipamento de acesso do assinante já falava Ethernet?

A banda larga queria Ethernet e uma sessão por assinante

A RFC 2516 deu uma resposta operacional. A Ethernet conectava vários equipamentos atrás de uma bridge na casa do assinante por um custo baixo. O PPP preservava controle de acesso, cobrança e uma sessão de serviço individual. A rede doméstica compartilhava um meio local; o provedor mantinha uma sessão PPP separada para cada usuário.

Esse acordo cobrava oito bytes de cada pacote. O provedor mantinha o limite da sessão, enquanto o pacote IP do assinante perdia oito bytes dentro do payload Ethernet convencional de 1.500. A RFC 2516 declarou a fronteira em vez de deixar os equipamentos adivinharem se o próximo enlace teria espaço sobrando.

A diferença aparecia quando uma ponta esperava uma unidade PPP de 1.500 bytes e a outra negociava 1.492. A introdução da RFC 4638, de 2006, descreve como caminhos de banda larga com essas diferenças podiam produzir muitos fragmentos. A extensão pretendia reduzir essa fragmentação nas redes de banda larga da geração seguinte.

Oito bytes viraram uma capacidade negociável

A RFC 4638 não fez todas as sessões PPPoE ultrapassarem 1.492. Para os projetos de banda larga da geração seguinte que descreve, ela exige que um BRAS atuando como servidor PPPoE aceite negociar acima desse valor; a tag opcional PPP-Max-Payload determina se um cliente e um servidor específicos podem usar o tamanho maior. O valor de dois bytes indica o payload PPP máximo que o cliente suporta nos dois sentidos. Para pedir mais de 1.492, o cliente inclui a tag em PADI e PADR. Um servidor capaz de atender ao pedido a devolve em PADO e PADS.

O servidor também tem um limite próprio. A RFC 4638 permite negociar um MRU maior conforme a configuração local e o máximo declarado pelo cliente. A escolha não pode exceder o menor entre o valor da tag e o MTU da interface do servidor menos oito. A tag inicia uma negociação; ela não aumenta a capacidade física da interface nem muda a configuração de um segmento no caminho.

Assim, um número se tornou uma sequência de decisões. O cliente pode pedir mais. O concentrador pode responder apenas dentro do que suporta. A interface local precisa acomodar o encapsulamento. Cada segmento Ethernet no caminho tem de transportar o pacote resultante. Ver 1.500 bytes na tela do assinante não significa que todos os switches entre a casa e o concentrador aceitaram esse tamanho.

O caminho também pode dizer não

A RFC 4638 descreve um teste depois que a sessão começa. O transmissor pode enviar um Echo-Request do tamanho do MRU pelo receptor e pelos equipamentos Ethernet intermediários. Se o teste maior não recebe Echo-Reply, mas o de 1.492 bytes recebe, o transmissor não deve enviar pacotes maiores naquela sessão.

Esse retorno ao limite menor importa. Sem a troca da tag, ou se uma das pontas não tiver uma configuração maior, continua valendo o teto de 1.492 bytes da RFC 2516. Se o caminho reprovar o teste maior, a conexão também pode voltar ao tamanho anterior. O acordo antigo permanece como piso funcional; caminhos compatíveis podem negociar para cima.

Uma opção publicada não ampliou o padrão Ethernet

A RFC 4638 é Informational. A nota do IESG anexada ao documento afirma que, na época da publicação, nenhum padrão IEEE vigente suportava jumbo frames acima de um MTU de 1.500 bytes e alerta que extensões não padronizadas não tinham interoperabilidade ou confiabilidade garantidas. As pontas PPPoE podiam propor um valor maior, mas cada porta Ethernet ainda precisava aceitá-lo de fato.

Por isso, a história não é “1.492 virou 1.500”. A RFC 4638 manteve o limite de 1999 onde o caminho precisava dele, definiu a troca de capacidades e deu às implementações um teste para pacotes maiores. O protocolo pode registrar uma oferta. Os equipamentos participantes e o caminho decidem se ela funciona.

As RFCs documentam o desenho e o objetivo de reduzir fragmentação, mas não identificam quais redes de acesso habilitaram a tag. Uma configuração de concentrador datada ou uma captura real da descoberta PPPoE confirmaria a implantação em uma rede específica.

Fontes