Resumo
- O RFC 3963 permitiu que um Mobile Router mudasse a ligação externa de um ou mais Mobile Network Prefixes sem envolver os nós internos; um Binding Acknowledgement positivo com R confirmava processamento e encaminhamento, não alcançabilidade individual.
- Modos explícito, implícito e de roteamento dinâmico usavam origens distintas para os prefixos. Operações responsáveis preservam autorizações, rotas, túnel, sondas, sessões e resultado de serviço como comprovantes separados.
Uma rede dentro de um ônibus ou navio pode manter sua numeração enquanto muda de acesso à Internet. Sensores e terminais continuam vendo o mesmo gateway. Quem muda de posição é o Mobile Router. Publicado em janeiro de 2005, o RFC 3963 chamou esse mecanismo de NEMO Basic Support e fez da mobilidade uma função da borda, não de cada Mobile Network Node.
Fora da rede doméstica, o roteador obtinha um Care-of Address e enviava um Binding Update ao Home Agent. A flag R pedia tratamento de roteador móvel. O agente associava o Home Address estável à localização temporária e configurava o encaminhamento dos prefixos autorizados. Um túnel bidirecional passava a transportar o tráfego entre o Home Agent e o roteador.
O sucesso tinha alcance definido. Status zero e R em um Binding Acknowledgement permitiam ao Mobile Router concluir que a atualização fora processada e o encaminhamento dos prefixos instalado. A resposta não interrogava cada dispositivo, não reabria sessões e não comprovava autorização de aplicações. Era recibo do plano de controle para endereços, prefixos e túnel.
A flag descrevia uma função, não criava identidade
O Mobile Router levantava R na solicitação, e o Home Agent o repetia ao aceitar. O bit mudava a semântica do processamento, mas não autenticava o remetente. O RFC exigia IPsec para a sinalização entre as duas partes. A associação protegida sustentava a autenticidade; R dizia qual serviço era solicitado dentro dela.
Um registro útil guarda Home Address, Care-of Address, sequência, validade, flags H e R, opções exatas de prefixo, associação IPsec, resposta, extremidades do túnel e rotas criadas. Reduzir tudo a binding=ok perde o limite da prova. Nem mesmo o conjunto completo observa diretamente os equipamentos internos.
O contexto técnico ajuda. O RFC 3775 era a base de Mobile IPv6 para hosts, mais tarde revisada pelo RFC 6275. O RFC 3963 colocou uma rede atrás do endpoint móvel. Um binding passou a representar mais endereços, não mais conhecimento sobre eles.
Três origens para o mesmo estado de encaminhamento
No modo explícito, o Binding Update carregava uma ou mais opções Mobile Network Prefix. O Home Agent podia conferi-las contra uma Prefix Table com as autorizações daquele roteador. O tratamento era atômico: se não pudesse encaminhar todos os prefixos listados, não deveria encaminhar nenhum e rejeitaria com status 141. Prefixo não autorizado produzia 142.
O tudo-ou-nada evitava que uma confirmação ocultasse uma rede apenas parcialmente movida. Ainda assim, coincidência com a tabela provava autoridade administrativa, não que todo nó dentro do bloco estava vivo.
No modo implícito, o pedido não continha opção de prefixo. O Home Agent recorria a informação pré-configurada; sem ela, respondia 143. Portanto, dois sucessos iguais na rede poderiam nascer de evidências diferentes: dados presentes na mensagem ou cadastro mantido fora dela. A auditoria precisa registrar modo, revisão, responsável e momento da configuração.
Um protocolo de roteamento dinâmico no túnel era uma terceira fonte. Podia acompanhar mudanças, mas também revelar a topologia interna; por isso o RFC recomendava confidencialidade ESP para essas mensagens. “Há uma rota” é uma descrição incompleta até sabermos se ela era estática, explicitamente solicitada, implicitamente configurada ou aprendida.
O próprio RFC fez a ressalva decisiva sobre rotas estáticas. Elas reduziam sinalização, porém podiam permanecer quando o Mobile Router correspondente já não estava alcançável. Estado de intenção e estado de vida não eram a mesma coisa.
O caminho central concentrava simplicidade e falha
No suporte básico, o tráfego dos Mobile Network Nodes para Correspondent Nodes passava pelo Home Agent. Na descida, o agente encapsulava para o Care-of Address. O Mobile Router verificava que a origem externa era seu Home Agent, salvo proteção equivalente por IPsec em modo túnel, e só entregava internamente quando o destino pertencia a um Mobile Network Prefix.
Na subida, o roteador rejeitava origens internas fora dos prefixos e o Home Agent repetia uma verificação topológica antes de liberar os pacotes. Esses filtros impediam falsificação de endereço. Não eram autenticação de usuário nem autorização de negócio.
O suporte básico não definiu otimização de rota para os prefixos móveis. Roteadores aninhados podiam formar uma árvore e multiplicar túneis. RFC 4885, RFC 4886 e RFC 4887 organizaram termos, objetivos e problemas. RFC 4888 examinou as dificuldades de otimização, e RFC 4889 o espaço de soluções. Uma rota instalada não era uma rota ótima.
Documentos posteriores acrescentaram controles vizinhos. RFC 5488 e RFC 6276 trataram de delegação DHCPv6 de prefixos para redes móveis; RFC 6089 tratou de flow bindings. Eles criaram novos fatos a registrar, sem transformar o acuse básico em teste de nó.
O histórico oficial está no registro do RFC Editor, na busca de erratas, no Datatracker e no registro IANA Mobility Parameters. Essas fontes sustentam status, correções reportadas e números coordenados. Não demonstram adoção nem execução correta em uma rede concreta.
O ledger operacional deve acompanhar a cadeia inteira: detecção de movimento; endereços; conteúdo, sequência e vida do update; modo de descoberta dos prefixos; evidência de autorização; decisão atômica; confirmação; IPsec; túnel; identidade de cada rota instalada ou retirada; filtros; testes por prefixo; resposta dos nós; sessões e serviços. Cada etapa responde apenas pelo que consegue observar.
O RFC 3963 ensinou a mover muito estado com uma troca pequena. A lição institucional é simétrica: manter pequeno também o mandato de cada comprovante.
Fontes
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
