Resumo

  • Antes de definir quatro opções de compatibilidade, o RFC 1888 recomendou redesenhar nativamente para IPv6 os planos OSI existentes.
  • Um mapeamento reversível não fazia uma Area com vários enlaces virar uma sub-rede, não agregava famílias distintas de prefixos nem convertia identidade de host em identidade de interface.
  • O RFC 4048 separou mecanismos aparentemente sem uso de dois erros na direção inversa; o RFC 4548 corrigiu apenas o fragmento de numeração que continuava útil.

O ativo preservado não incluía o plano de controle

Publicado como Experimental em agosto de 1996, o RFC 1888 não especificava um padrão da Internet. Sua primeira recomendação era desenhar um plano IPv6 nativo e remapear conscientemente a topologia local, sempre que uma organização já tivesse planejado ou implantado NSAPs OSI.

Havia três motivos. Uma Area em OSI/IS-IS podia abranger vários enlaces físicos; uma sub-rede IPv6 pressupunha um único enlace. Copiar o número da Area para o campo de sub-rede preservava uma etiqueta e apagava a fronteira física que a descoberta precisava conhecer.

Na escala ampla, agregação exigia um prefixo comum. Endereços IPv6 normais e os derivados de NSAPA restrita não ganhavam esse prefixo só por pertencerem ao mesmo projeto. A transformação podia ser perfeita item a item e, ainda assim, aumentar a quantidade de rotas.

Também mudava o objeto identificado. Vários NSAPs podiam representar um sistema final como um todo, atravessando interfaces. IPv6 endereça interfaces. A fórmula não selecionava a interface alcançável no último enlace. O RFC também não migrava ES-IS, IS-IS ou sua infraestrutura; os bytes viajavam sem o mecanismo que lhes dava alcance.

Quatro formas de adiar uma decisão

A primeira colocou uma NSAPA ICD ou DCC restrita em dezesseis octetos IPv6 iniciados por 0x02. Era algorítmica e reversível no subconjunto permitido, mas o texto avisava sobre roteamento ineficiente e sobre a falta de uma solução para uma Area com várias sub-redes físicas.

A segunda começou com 0x03 e truncou a NSAPA. A hierarquia restante podia aproximar o pacote da Area correta, porém a identidade completa tinha de seguir numa opção de destino NSAPA ou num pacote CLNP encapsulado. O receptor decidia encaminhar, desencapsular ou descartar. Descoberta automática final não foi definida; mapeamento estático ou um futuro mecanismo semelhante a ES-IS eram apenas possibilidades.

A lacuna atingia diagnósticos. Autoconfiguração e descoberta comuns não funcionavam sem mudança, NSAPAs completas não podiam entrar simplesmente no cabeçalho de roteamento IPv6 e um erro ICMP enviado ao endereço truncado podia ser descartado antes de chegar à origem real. A compatibilidade conseguia esconder a falha e perder o recibo dela.

A terceira manteve IPv6 normal e anexou uma opção com NSAPA completa para interpretação no destino. Nós que não usassem a função não precisavam implementá-la. A presença da opção provava oferta de informação, não suporte ou ação.

A quarta colocou IPv6 dentro de uma NSAPA de vinte octetos, sob IANA AFI 35 e ICP zero. Embutimentos recursivos eram proibidos para evitar anomalias e loops associados ao RFC 1326. O RFC 1629 contextualiza NSAP sobre ATM e o RFC 3513 a arquitetura IPv6 posterior; nenhum deles comprova adoção do RFC 1888.

O que foi aposentado e o que foi corrigido

Em 2005, o RFC 4048 disse que, até onde o IETF sabia, os mapeamentos de NSAP em IPv6 nunca haviam sido usados seriamente e não tinham suporte nas implementações IPv6. É uma avaliação histórica atribuída, não um censo universal. Ela embasou a recomendação de Historic e a devolução do prefixo anterior a Reserved.

Na direção IPv6-em-NSAPA, porém, surgira interesse, inclusive para ATM. A seção 6 tinha dois erros: ICP ocupava dezesseis bits, dois octetos, não apenas o terceiro; e o IDI de quatro dígitos decimais era codificado em dois octetos BCD, não como inteiro binário livre.

O RFC 4548 substituiu somente essa seção em 2006. Sob AFI 35, ICP decimal 0 indica o formato IPv6 e 1, IPv4. De 2 a 9999, uma atribuição exige formato definido e publicado e consenso do IETF. O atual registro IANA OSI NSAPA Numbers preserva esses significados, não prova código em execução ou tráfego.

As páginas informativas do RFC Editor para RFC 1888, RFC 4048 e RFC 4548 registram estado e substituição. Corrigir o uso do ICP não ressuscitou NSAPAs restritas ou truncadas dentro de IPv6. O processo salvou um elemento estreito de namespace, sem salvar a arquitetura ao redor.

A ordem da prova fica clara: plano documentado, conversão reversível, sintaxe válida, código registrado, parser, função ativada, rota, último salto, decisão do receptor, resultado da aplicação e observação de uso. Cada etapa precisa do próprio recibo.