Resumo

  • A RFC 5380 separa a RCoA estável da LCoA atual e usa o MAP para manter a correspondência durante movimentos locais.
  • O controle pode aceitar o binding enquanto encapsulação, rota, MTU ou processamento no destino impedem que o tráfego da aplicação complete o caminho.

Um pacote de controle não representa a carga

O móvel registra uma nova LCoA no Mobility Anchor Point. O pedido é autenticado, cabe no caminho e recebe um Binding Acknowledgement. O home agent e os correspondent nodes continuam usando a Regional Care-of Address. Nada no identificador externo mudou.

Em seguida chega um pacote de aplicação maior. Entre o interlocutor e o móvel, o MAP precisa interceptá-lo e criar um cabeçalho externo para o túnel. Se um home agent também participa, outra encapsulação pode existir. A margem disponível para o conteúdo diminui.

A RFC 5380 manda considerar essa sobrecarga ao calcular o MTU oferecido às camadas superiores. A instrução revela por que “binding aceito” e “dados entregues” pertencem a recibos diferentes. A mensagem curta que criou o estado não testa necessariamente a condição que enfrentará o tráfego útil.

O documento não relata uma falha específica nem garante que ela ocorra. Ele delimita uma dependência que a operação deve medir.

A direção estável depende de um endereço que muda

HMIPv6 atribui ao móvel uma RCoA ligada ao MAP e uma LCoA ligada ao acesso atual. Dentro do mesmo domínio MAP, movimentos alteram a LCoA sem obrigar home agent e interlocutores a aprender outro endereço. O MAP funciona como um home agent local: mantém o binding, recebe pacotes pela RCoA e os encaminha pelo túnel à LCoA.

Essa indirection reduz sinalização distante e pode acelerar handovers. Ela também transfere a verdade operacional para um estado local que os pares não veem. A RCoA parece imóvel porque o MAP atualiza o destino escondido.

Logo, o registro que interessa não é apenas o endereço regional. É o conjunto formado por RCoA, LCoA, identidade do MAP, sequência e validade do binding, associação de segurança, rota do túnel, MTU útil e última evidência de entrega.

O acknowledgement não fecha a cadeia

Depois de aceitar a Binding Update local, o MAP devolve um acknowledgement válido. O móvel deveria aguardar essa resposta antes de registrar a RCoA com outros nós. A validade desses bindings externos não pode ultrapassar a validade do binding com o MAP.

Essa regra impede que uma promessa externa sobreviva à condição interna que a torna verdadeira. Mas ela não elimina as etapas posteriores. O MAP ainda precisa capturar o pacote, selecionar a entrada certa, encapsular e rotear. O móvel precisa receber, desencapsular e processar. A aplicação precisa manter sua transação.

Um sistema de incidentes deve preservar cada marco. “Update enviada”, “binding aceito”, “primeiro pacote encaminhado”, “primeiro pacote recebido” e “primeira operação útil” não são variantes da mesma coluna.

Preferência escolhe; não observa

Router Advertisements transportam opções de MAP com endereço, prefixo, distância, preferência e validade. O móvel guarda essas informações e escolhe pelo menos uma âncora. Preferência é uma indicação de política do operador. Distância participa da seleção, sem necessariamente representar a rota real em saltos.

Validade zero é uma retirada inequívoca. O MAP não deve ser escolhido, bindings existentes podem ser considerados perdidos e outra âncora deve ser usada. Sem alternativa, o móvel não deve continuar com HMIPv6.

Validade positiva não mede capacidade, perda, latência, cache ou MTU. A regra para o zero não autoriza inverter a frase. A ausência de retirada é uma condição administrativa, não um resultado de dados.

A antiga âncora entra no caminho

Ao mudar de domínio MAP, o móvel pode atualizar a âncora anterior para que pacotes em trânsito sejam encaminhados à nova localização. O operador pode restringir forwarding fora do domínio, embora o padrão recomende certa cooperação entre domínios vizinhos.

Durante esse intervalo, há dois caminhos e vários relógios. O MAP antigo mantém uma ponte temporária. O novo MAP mantém o estado atual. Home agent e interlocutores podem atualizar a RCoA em momentos próprios.

Encerrar a ponte por tempo fixo é simples, mas não suficiente. O critério deve combinar aceitação do novo binding, observação de tráfego bidirecional, drenagem do caminho antigo e uma transação de serviço. Caso contrário, o sistema pode remover a única rota que ainda entregava ou conservar uma dependência que já deveria ter desaparecido.

Segurança valida o escritor, não o efeito

A relação móvel–MAP exige autenticação mútua, integridade e proteção contra replay. O MAP também pode rejeitar LCoAs fora de uma lista de prefixos locais válidos. Essas regras defendem o plano de controle contra escritores indevidos e posições incompatíveis com a política.

Elas não atestam o plano de dados. Uma LCoA autorizada pode estar inalcançável. Uma atualização íntegra pode instalar um destino cuja rota falhou. Um túnel autenticado pode ter MTU insuficiente para a carga. A força criptográfica torna a declaração estreita mais confiável; não a transforma em declaração sobre o serviço.

A continuidade local tem limite de domínio

A RFC permite usar a RCoA diretamente como endereço de origem para comunicações curtas, sem Home Address option. Para o interlocutor, o móvel parece um nó fixo enquanto permanece no domínio. O ganho evita parte do custo global de Mobile IPv6.

O limite é explícito: quando a RCoA muda ao entrar em outro domínio MAP, essa comunicação local se rompe. A estabilidade nunca foi universal. Ela pertencia ao perímetro que sustentava o endereço.

O mesmo cuidado aparece na proibição de usar uma RCoA criada por um MAP como care-of address registrado em outro. A hierarquia produziria encapsulações adicionais e reduziria eficiência. Componentes válidos podem formar uma composição ruim.

Distribuir âncoras multiplica associações

A RFC 7429 descreve HMIPv6 como forma de reduzir centralização da sinalização, mas aponta lacunas em descoberta, seleção, realocação e transferência de contexto. A RFC 5380 permite vários MAPs e RCoAs para grupos diferentes de interlocutores. Essa flexibilidade exige saber qual âncora realiza cada endereço e sessão.

“Há três MAPs disponíveis” não é recibo de continuidade. É inventário de capacidade. O estado corrente precisa ligar sessão, RCoA, LCoA e âncora, com validade e evidência de tráfego.

O caminho que o cadastro não vê

Running-Code Primacy, na formulação de Heng Lu, separa possibilidade especificada de efeito executado. O binding é um registro necessário. O pacote observado é evidência do efeito. A transação concluída é outra evidência.

Para HMIPv6, a sequência auditável passa por descoberta, seleção, endereçamento, registro, persistência do cache, forwarding, caminho, recepção e aplicação. A automação deve parar no primeiro recibo ausente, não reutilizar o último sucesso conhecido.

O cadastro estava certo. Quem mede o caminho que ele não consegue ver?

Fontes