Resumo

  • Nos campos herdados TCP_SPACE e NON_TCP_SPACE do RFC 2509, zero era o identificador de contexto máximo; o CID 0 continuava sendo um contexto disponível.
  • A subopção 3, com três octetos, permitiu ao RFC 3544 definir explicitamente zero contextos TCP ou não TCP e desativar aquela classe.

A armadilha estava no nome. TCP_SPACE e NON_TCP_SPACE não contavam contextos: indicavam o maior identificador em cada espaço. Se o máximo fosse zero, o espaço ainda incluía o CID 0. Isso podia servir para uma configuração mínima, mas não expressava “não comprima nenhum pacote desta família”.

Publicado em julho de 2003 como Proposed Standard, o RFC 3544 revisou a opção de negociação PPP do RFC 2509 sem mudar o sentido herdado desses campos. A subopção 3 trouxe a distinção que faltava: tipo 3, comprimento de três octetos e um parâmetro de um octeto. O valor 1 significa zero contextos TCP; o valor 2, zero contextos não TCP. A subopção sobrescreve o valor correspondente de TCP_SPACE ou NON_TCP_SPACE. Se os dois valores forem incluídos, a compressão é desativada para todos os pacotes.

É uma correção de compatibilidade por meio de uma sobrescrita explícita, não uma redefinição do zero. Os campos antigos mantêm o significado conhecido; um sinal adicional carrega a intenção que eles não comportavam. Alterar diretamente o sentido dos bits faria pares antigos e novos interpretarem o mesmo valor de maneiras distintas.

Dois NCPs, duas negociações

O PPP negocia parâmetros do enlace por meio de Protocolos de Controle de Rede. O RFC 3544 define o mesmo formato de opção para o IPCP, em IPv4, e o IPV6CP, em IPv6. Cada NCP configura a compressão dos pacotes cuja camada de rede externa corresponde àquela versão. Portanto, negociar compressão para IPv4 e para IPv6 produz dois resultados separados no plano de controle, não um único interruptor.

Há uma sutileza adicional: IPv4 e IPv6 compartilham o espaço de identificadores de contexto, embora os valores sejam negociados separadamente. Quando os parâmetros diferem, o mecanismo de compressão precisa alocar identificadores de um conjunto comum, e o descompressor deve consultar o estado do contexto para saber quais parâmetros aplicar. TCP e o conjunto não-TCP/UDP/RTP não compartilham esse espaço. São restrições de funcionamento previstas no protocolo; não provam que um par específico as configurou ou usou.

O RFC 3544 também acrescenta a subopção RTP aprimorada, tipo 2, que é negociada no lugar — e não junto — da antiga subopção RTP 1. Com os nove valores do campo de protocolo PPP, essas opções permitem ao receptor classificar o quadro e reconhecer os formatos negociados que podem ser usados. O campo de protocolo demultiplexa; a subopção registra a intenção de configuração.

O que uma opção negociada não demonstra

Depois de uma negociação bem-sucedida, os identificadores de protocolo indicados podem ser usados. Isso não mostra que a implementação transmitiu um quadro comprimido, que o outro lado o decodificou, que o datagrama chegou ao destino ou que ficou menor. São observações diferentes em pontos diferentes do caminho. A troca de configuração comprova um conjunto de parâmetros acordado, não a entrega do tráfego.

O próprio documento registra uma ambiguidade próxima: o RFC 1332 não esclarece se a opção descreve a capacidade do emissor ou a do receptor. O RFC 3544 afirma que, de acordo com a prática, presume que uma Config-Req descreve o descompressor do par que a envia. Trata-se de uma suposição declarada, não de uma nova interpretação normativa do RFC 1332. Afirmar algo mais forte apagaria a ressalva do texto.

O plano de dados tem outra condição. O IPHC usa codificação diferencial em TCP e RTP, e os pacotes comprimidos dependem de um contexto compartilhado pelas duas pontas. O PPP não reordena pacotes; por isso, as proteções contra reordenação vêm desativadas por padrão. Se o Multi-Link PPP multiclasses ou outro mecanismo puder reordenar, os pacotes que compartilham contexto precisam manter a ordem. Negociar um formato não elimina essa restrição de transporte.

A lição histórica é delimitada: a evolução de um protocolo às vezes exige um segundo sinal porque o valor mais intuitivo já possui um significado válido. O RFC 3544 preservou o campo, acrescentou uma sobrescrita explícita e manteve capacidade, transmissão, decodificação, entrega e desempenho como fatos distintos a verificar.

Fontes