Resumo

  • O RFC 5213 transfere a sinalização de mobilidade do dispositivo para a rede. O MAG detecta a conexão e envia um PBU em nome do nó; a resposta positiva comprova que o LMA aceitou uma declaração autenticada e autorizada.
  • Essa resposta não comprova que a observação de acesso continua verdadeira, que o MAG concluiu túnel e encaminhamento, que o aparelho recebeu o anúncio e configurou o endereço, nem que a sessão de aplicação sobreviveu.

Um protocolo construído ao redor do silêncio

No Proxy Mobile IPv6, o terminal não precisa executar um cliente de mobilidade. Dentro de um domínio administrado, a infraestrutura identifica o nó, consulta sua política e mantém o mesmo prefixo enquanto ele muda de enlace. Para o aparelho, o processo se parece com IPv6 comum.

O Local Mobility Anchor (LMA) é o ponto topológico do prefixo de rede residencial. O Mobile Access Gateway (MAG) fica junto ao acesso. Ao perceber uma chegada, o MAG obtém o identificador e o perfil do nó e envia um Proxy Binding Update. Se aceitar a solicitação, o LMA cria ou atualiza a entrada de binding, associa prefixo e MAG, prepara sua ponta do túnel e devolve um Proxy Binding Acknowledgement.

Uma resposta positiva tem conteúdo operacional. Ela comprova que o LMA recebeu uma mensagem protegida de um par que julgou autorizado para aquele nó e que realizou as mudanças previstas do lado da âncora. Não há motivo para diminuir esse fato.

Há, sim, motivo para não ampliá-lo. O dispositivo não assinou o PBU. Um mecanismo de acesso afirmou que ele chegou; outra função forneceu a identidade; uma política permitiu ao MAG representá-lo. O LMA aceitou essa cadeia. A arquitetura é de delegação, não de testemunho direto do terminal.

Credencial válida, premissa ainda verificável

O RFC exige confiança entre MAG e LMA. PBU e PBA precisam de proteção, e o suporte a IPsec é obrigatório. O LMA também deve verificar a autorização do MAG para atualizar o binding do nó específico. Autenticação identifica o emissor, integridade protege o conteúdo e autorização limita o objeto da fala.

Nenhuma dessas propriedades mede novamente o enlace de acesso.

A chegada pode vir de associação sem fio, autenticação de rede, mudança de porta ou outro evento dependente da tecnologia. O RFC 5213 não define como a detecção acontece. O MAG recebe esse resultado e o transforma em uma mensagem de mobilidade. Se a observação estiver atrasada, se a identidade for vinculada ao aparelho errado ou se o nó já tiver saído, a criptografia protege uma afirmação cuja premissa envelheceu.

A própria seção de segurança explicita o problema. Um MAG comprometido pode declarar que um nó está conectado sem que isso seja verdade. Uma mitigação seria uma entidade confiável confirmar o acesso real antes da aceitação pelo LMA; o método fica fora do escopo. A existência dessa verificação adicional mostra por que autenticar o representante não autentica o cenário representado.

O princípio se liga às notas de Heng Lu: visibilidade não se converte automaticamente em autoridade, e autoridade não se converte em execução. O mandato do MAG é legítimo e delimitado. Não faz dele sensor físico do dispositivo nem observador da aplicação.

A metade que começa depois do sucesso

O LMA processa primeiro. Ao aceitar o PBU, atualiza o cache, escolhe ou preserva o prefixo, configura rota e sua extremidade do túnel e envia o PBA. Só então o MAG recebe e autentica a resposta, atualiza sua lista local, estabelece a outra ponta, instala encaminhamento e envia Router Advertisements no enlace do nó.

Um painel que marca “handover concluído” na geração do PBA conhece o estado da âncora, não o estado final da borda. A resposta pode não chegar ao MAG; a rota local pode falhar; o anúncio pode não ser transmitido.

Depois vem o trabalho do terminal. Neighbor Discovery regula o recebimento do anúncio. Autoconfiguração e Duplicate Address Detection têm condições próprias. O objetivo do PMIPv6 é manter o prefixo e esconder a mobilidade do nó, mas esse objetivo não observa se o RA chegou, se o endereço ficou utilizável, se o roteador padrão está correto ou se pacotes passaram nos dois sentidos.

Uma chave GRE pode separar contextos de túnel; atribuição dinâmica de LMA e opções de qualidade de serviço ampliam o controle. Ainda assim, precisão de identificação não é recibo de entrega. Um túnel pode existir com encaminhamento desatualizado, bloqueio de política ou aplicação já expirada.

O cache governa a rota, não a presença

O binding cache tem poder real. O LMA o consulta para decidir para qual MAG encaminhar os pacotes. A entrada carrega lifetime e sequência; atualizações e cancelamentos mudam o comportamento em produção.

Essa autoridade não transforma o cache em sensor contínuo. Durante uma transferência, o MAG antigo pode informar desligamento enquanto o novo informa conexão. As mensagens podem se cruzar, atrasar ou se perder. Uma entrada dentro do lifetime quer dizer que a declaração aceita ainda não expirou segundo o protocolo — não que o LMA tenha visto o aparelho naquele instante.

Na análise de incidente, a equipe deve localizar a primeira quebra: quem observou a conexão? Como o identificador foi obtido? A autenticação de acesso correspondeu ao mesmo sujeito do perfil? O MAG tinha permissão específica? O novo MAG recebeu o PBA? Instalou o túnel e o encaminhamento? O RA chegou? O caminho antigo foi removido cedo demais? O tráfego falhou na ida, na volta ou na aplicação?

Comprimir essa sequência em um único carimbo de conclusão elimina as fontes e os relógios necessários para responder. O dado final pode orientar roteamento e ainda ser insuficiente para explicar a falha.

Um recibo para o handover delegado

O recibo operacional proposto por BTW vincula: tecnologia, observador, horário e confiança do evento de acesso; origem do identificador; autenticação e política; identidade e autoridade por nó do MAG; sequência e lifetime do PBU; eventual confirmação independente; geração do binding, prefixo, rota e túnel no LMA; status do PBA e recepção autenticada no MAG; túnel e encaminhamento na borda; emissão e recepção do anúncio; endereço e DAD no terminal; testes bidirecionais; resultado de aplicação; e retirada do estado antigo.

Não se trata de requisito novo do RFC 5213. É uma disciplina editorial para que automação, assurance e relatórios não apaguem os donos das evidências que o protocolo mantém separados.

O registro do LMA tem autoridade sobre a rota que o software executará. Não tem autoridade para tornar verdadeira, retroativamente, uma observação de acesso. O MAG pode falar pelo terminal na sinalização; não pode falar pela recepção do terminal ou pela experiência da aplicação. Running code exige a próxima prova no ponto que executa a próxima ação.

O sistema mais confiável não é o que colore o PBA de verde mais rápido. É o que mostra, sem atalhos, quem observou, quem autorizou, quem executou e qual resultado ainda falta.

Fontes

  1. RFC 5213 em HTML
  2. IETF Datatracker: RFC 5213
  3. Informações do RFC 5213
  4. Histórico do RFC 5213
  5. RFC 6543 — suporte do MAG a múltiplas interfaces
  6. RFC 7864 — atualização da especificação PMIPv6
  7. RFC 3775 — mobilidade em IPv6
  8. RFC 4283 — opção de identificador do nó móvel
  9. RFC 4832 — terminologia de mobilidade
  10. RFC 4861 — Neighbor Discovery do IPv6
  11. RFC 4862 — autoconfiguração de endereços IPv6
  12. RFC 4301 — arquitetura de segurança IP
  13. RFC 4303 — Encapsulating Security Payload
  14. RFC 4306 — Internet Key Exchange
  15. RFC 2473 — tunelamento IPv6 genérico
  16. RFC 5845 — chave GRE para PMIPv6
  17. RFC 6463 — atribuição de LMA em tempo de execução
  18. RFC 8127 — opções de qualidade de serviço PMIPv6
  19. Heng Lu — primazia do código em execução