Resumo

  • A RFC 3355 mapeou L2TP sobre um circuito virtual ATM AAL5, mas exigiu que cada PDU L2TP coubesse em um único PDU AAL5; o MTU do meio limitava o túnel e todas as sessões PPP.
  • Escolha de encapsulamento, estabelecimento, proteção e remoção do VC continuavam fatos do meio. Negociar o formato não provava entrega interna, e limpar o SVC terminava as sessões.

O túnel oferece uma aparência simples: um ponto remoto parece ligado por um enlace. Por baixo, ATM monta circuitos, negocia parâmetros e segmenta informação. A utilidade do L2TP estava em poupar as sessões PPP desses detalhes. A limitação continuava ali: a unidade exterior tinha tamanho e vida finitos.

Publicada em agosto de 2002 no Standards Track, a RFC 3355 especificou L2TP sobre ATM Adaptation Layer 5. A especificação base dizia que L2TP era amplamente isolado do meio e precisava apenas de conectividade ponto a ponto orientada a pacotes. Um circuito virtual AAL5 podia prestar esse serviço entre LAC e LNS.

A regra principal exigia que um PDU L2TP inteiro fosse transportado em um único PDU AAL5. Por isso, o MTU da conexão AAL5 restringia o MTU do túnel e o MRU de todas as conexões PPP que o utilizavam. A abstração escondia células e sinalização, mas não aumentava o envelope.

O suporte mínimo era MRU PPP de 1500 octetos. Recomendava-se capacidade para um pacote IP de pelo menos 9180 octetos dentro do PDU PPP. Esses números descreviam obrigação de implementação e preferência de projeto, não um resultado observado. Um PVC poderia ter outro provisionamento, um SVC receber parâmetros diferentes e um par PPP negociar valor menor.

Assim, a ficha técnica que anuncia 9180 não prova a passagem de um pacote desse tamanho. É necessário conhecer cabeçalhos, parâmetros reais do VC, MRU negociado, outros limites, fragmentação e descartes. Um ping pequeno bem-sucedido também não confirma o maior envelope.

AAL5 era tratado como enlace bit-síncrono, full-duplex e ponto a ponto. O VC podia ser permanente ou comutado sob demanda. Usava-se message mode não assegurado sem entrega corrompida; a fronteira fornecia apenas octetos completos. Preservar mensagens e validar CRC não oferecia confiabilidade completa, identidade ou sigilo.

Havia dois modos de nomear o conteúdo. LLC/SNAP levava em cada PDU o identificador IANA de L2TP. O VC multiplexado dispensava esse cabeçalho porque as pontas tinham acordado que o circuito continha L2TP. A identidade estava explícita no pacote ou implícita no contexto.

LLC em PVC era obrigatório. LLC em SVC e VC-multiplexing eram opcionais. Para PVC, as pontas precisavam da mesma configuração. Duas implementações L2TP poderiam interpretar os bytes de modo diferente se o acordo exterior estivesse divergente.

No SVC, a sinalização ATM usava elementos B-LLI. O chamador oferecia LLC, VC-multiplexing ou ambos em preferência. Se a chamada com ambos fosse aceita, o chamado escolhia exatamente um. Uma oferta somente com modo não suportado tinha de ser rejeitada.

O resultado dessa negociação era limitado: as partes escolheram como interpretar o payload AAL5 daquela conexão. Não demonstrava que o controle L2TP abriu, PPP autenticou, o tamanho serviu, os dados chegaram ou a aplicação respondeu. A gramática do envelope tinha sido escolhida; o conteúdo ainda precisava viver.

As regras de reset expunham a dependência. Se um túnel em SVC fosse reiniciado, as duas pontas limpavam o SVC e todas as sessões de usuário eram terminadas. Uma nova solicitação poderia iniciar novo estabelecimento. Ela não preservava silenciosamente as sessões antigas.

Também quando o AAL5 SVC era removido, a implementação desmontava o túnel e devolvia a conexão de controle ao estado idle. O evento exterior retirava o enlace do qual o estado interior dependia. Isolamento de detalhes não era isolamento de falhas.

Depois de falha de estabelecimento, os critérios para considerar o par inalcançável e depois disponível eram decisões locais. Sem sessões ativas, qualquer ponta podia limpar o SVC. Estados como “inalcançável” e “idle” precisavam indicar camada, observador, evento e geração.

Qualidade de serviço mantinha a mesma divisão. Várias conexões AAL5 podiam separar qualidades de clientes. Inverse multiplexing de um túnel em vários VCs ficou para estudo futuro. Parâmetros do PVC eram acordados e os do SVC pedidos. Configuração e pedido não eram recibo de desempenho.

Segurança exigia outra camada. A RFC avisava que ataques à rede ATM podiam comprometer o túnel e indicava autenticação, payload cifrado ou segurança ATM. PID, B-LLI e CRC corretos não autenticavam o usuário nem protegiam o conteúdo.

A RFC 2661 define túneis e sessões L2TP; a RFC 1661, PPP e MRU; a RFC 2684, LLC e VC sobre AAL5; a RFC 2364, PPP direto sobre AAL5; a RFC 2331, sinalização ATM. A RFC 3070 usa Frame Relay e tem outra fronteira. A RFC 3193 adiciona IPsec. A RFC 4459 trata posteriormente de MTU e fragmentação em túneis de modo geral.

O registro IANA preserva valores coordenados de L2TP, não implantação. As fontes não demonstram produto, tráfego, adoção, incidente ou recuperação. Cada uma estabelece apenas o seu plano.

A RFC 3355 continua útil porque define uma abstração sem transformá-la em ficção. As sessões podiam ignorar ATM. O circuito AAL5 ainda determinava o tamanho de uma unidade, como reconhecê-la e quais sessões desapareciam quando ele era apagado. O meio ficou oculto, não impotente.

Sources