Resumo

  • RFC 5121 recomenda MTU IPv6 padrão de 1500 octetos, exige anúncio por Neighbor Discovery quando o valor for diferente e admite que o Path MTU revele outro limite.
  • A negociação de uma única subcamada de convergência decide como carregar IPv6, mas não comprova o fluxo de serviço, o CID, o túnel, o prefixo ou o tamanho que atravessa o caminho.
  • Um registro confiável preserva separadamente configuração, anúncio, associação topológica, captura de pacotes e resultado, inclusive o status não verificado do erratum sobre 2047/2048 bytes.

O número 1500 costuma chegar ao painel por uma fonte administrativa: um campo de configuração, um valor desejado, talvez um padrão. Ele parece objetivo o suficiente para virar um selo. RFC 5121, porém, coloca esse número dentro de uma cadeia de decisões. O MTU de um enlace 802.16 é configurável. O padrão recomendado para pacotes IPv6 é 1500. Se o valor usado for outro, o roteador de acesso precisa anunciá-lo na opção MTU de Router Advertisement. E o mecanismo de Path MTU Discovery ainda pode encontrar um limite diferente depois do enlace local.

Há pelo menos três números com proprietários distintos. Confundi-los produz um painel limpo e uma investigação ruim.

A aritmética também tem proveniência

O próprio texto fornece um pequeno teste de disciplina documental. A PDU MAC contém um cabeçalho de seis bytes, carga opcional e CRC opcional. O campo Len tem onze bits. RFC 5121 afirma então que o tamanho total pode ser 2048 bytes. O Errata ID 1768 observa que o maior valor representável por onze bits é 2047.

O ponto não é escolher silenciosamente o número mais convincente. O erratum está marcado como “Held for Document Update”, não como Verified. Uma ferramenta de engenharia deve transportar três elementos: o texto publicado, o raciocínio aritmético e o status editorial. Substituir 2048 por 2047 sem registrar a origem destrói custódia. Repetir 2048 sem a ressalva ignora uma qualificação conhecida.

Na operação, nenhum desses valores sozinho prova o MTU útil. A evidência vem de sondas de tamanho controlado, mensagens Packet Too Big, capturas nos limites do enlace e entrega observada. Um formulário não atravessa um túnel.

Antes do tamanho vem a escolha de transporte

IEEE 802.16 oferece mais de uma forma de carregar IPv6. RFC 5121 cobre a parte específica de IP da Packet Convergence Sublayer, embora reconheça o caminho via 802.3/Ethernet. Estação móvel e estação base anunciam capacidades no registro e indicam a subcamada no estabelecimento da conexão de transporte.

Se ambas suportam IP CS, ela é o modo padrão. Se ambas suportam IP CS e Ethernet CS, usam IP CS. Em qualquer caso, negociam no máximo uma subcamada de convergência para IPv6 naquele enlace. Sem opção comum, a conexão não é montada e o host não envia nem recebe IPv6 por ela.

Essa seleção é necessária, mas não cria o resto do caminho. A implementação da base deve suportar as encapsulações Standards Track definidas para 802.16, enquanto a configuração pode manter modos desativados. Portanto, suporte no produto, habilitação local, escolha negociada e uso por um pacote são fatos diferentes.

O pacote ainda precisa de classificador, fluxo e CID

O cabeçalho MAC genérico não identifica por si só o tipo da carga. Classificadores examinam endereços, Next Header, classe de tráfego e faixas de portas para mapear o pacote a um fluxo de serviço e a uma conexão. A conexão é identificada por CID, e vários CIDs podem existir entre a mesma estação móvel e a base.

Um indicador “IP CS negociado” não diz se a regra correta estava instalada, qual fluxo foi admitido, qual CID estava vigente ou se a PDU saiu. Para investigar uma falha de tamanho, é indispensável saber primeiro qual caminho o pacote tomou. Uma sonda em um CID não demonstra comportamento idêntico nos demais fluxos.

O registro mínimo liga cada pacote testado à versão do classificador, ao fluxo, ao CID, à estação e ao roteador de acesso. Sem isso, a equipe pode atribuir ao MTU uma falha causada por associação topológica.

Vários CIDs formam um enlace L3

RFC 5121 separa o enlace IEEE de camada 2 do enlace IPv6 de camada 3. Quando base e roteador de acesso estão juntos, a coleção das conexões de uma estação forma um único enlace. Quando estão separados, recomenda-se um túnel com granularidade não maior que por estação ou por fluxo. Túnel e conexões de transporte formam o enlace ponto a ponto entre estação e roteador.

Essa granularidade influencia a medição. Um túnel agregado pode impor overhead ou limite diferente; pode também misturar contextos que deveriam permanecer por estação. A prova precisa indicar onde o roteador termina, qual túnel corresponde ao terminal e em que ponto cada tamanho foi observado.

Cada estação pertence a um enlace diferente e deve receber prefixo ou prefixos únicos. Um ou mais /64 são recomendados, normalmente com flag on-link. Compartilhar a base não cria uma sub-rede compartilhada. O pacote de 1500 bytes só é uma sonda válida para o enlace pretendido se prefixo, túnel e CID também forem os pretendidos.

Otimizações dependem de condições observáveis

RFC 5121 permite considerar DAD redundante em certas situações, mas exige duas premissas: o prefixo anunciado deve ser exclusivo daquele enlace e o roteador de acesso não deve configurar para si um endereço global do mesmo prefixo. A etiqueta ponto a ponto não basta.

Da mesma forma, o terminal pode entrar em idle mode e desmontar o rádio. Para não acordá-lo, intervalos de RA podem ser longos e consultas periódicas de MLD não devem ser enviadas ao host dormente. O silêncio pode ser economia correta ou estado perdido. O monitor precisa do evento de dormência, do paging, do último RA, das memberships e do gatilho de revalidação.

Esses exemplos compartilham uma regra: a otimização só mantém validade enquanto suas premissas continuarem registradas. O controle que guarda apenas “DAD off” ou “host quiet” não conserva a razão que tornava a decisão segura.

Política de IID não é identidade do enlace

O RFC original exigia o uso do MAC de 48 bits para construir um identificador modified EUI-64, permitindo também mecanismos aleatórios de privacidade. RFC 8064 depois atualizou a orientação e recomendou não embutir endereços estáveis de camada de enlace em IIDs estáveis.

Mudou a política de formação do identificador, não o modelo de enlace por estação. Sistemas que usam a mesma chave para dispositivo, IID, endereço, CID e enlace transformam uma atualização normal em ruptura. Separar essas entidades permite adotar privacidade sem apagar histórico topológico.

Um painel útil admite contestação pelo pacote

O objetivo não é um controlador total. O contrato comum pode exigir apenas identificadores estáveis, exportação dos eventos, vínculo entre estação, CID, túnel, prefixo e roteador, e um método reproduzível de teste. As decisões locais de automação e capacidade continuam substituíveis.

A hierarquia de evidência precisa permanecer visível. Capacidade descreve potencial. Negociação registra escolha. Fluxo e CID registram conexão. RA registra configuração apresentada ao host. A sonda registra comportamento num momento e caminho. O resultado registra efeito sobre o serviço. Quando o painel mostra 1500, ele deve também mostrar qual dessas afirmações está fazendo.

Fontes