Resumo

  • O RFC 3344 permitia marcar o bit S na solicitação de registro para aceitar um novo care-of address sem remover os vínculos de mobilidade anteriores.
  • Com suporte a vínculos simultâneos, o agente de origem enviava uma cópia de cada datagrama a todos os endereços ativos; o registro mais recente não provava exclusividade nem retirada do caminho antigo.

Um cadastro de mobilidade parece, à primeira vista, um campo que muda: endereço de origem fixo, care-of address atual, prazo. O RFC 3344 autorizou uma forma diferente. O mesmo endereço de origem podia apontar para várias linhas ativas, com tempos independentes, e o agente de origem podia encaminhar por todas elas.

Essa pluralidade tinha um comando explícito. O bit S, de simultaneous bindings, dizia que o nó móvel queria preservar os vínculos anteriores. Sem ele, ou sem capacidade no agente de origem, o novo registro substituía o conjunto antigo.

Um care-of address não era um certificado de lugar

Mobile IPv4 mantinha o endereço de origem quando o nó saía de sua rede. O care-of address identificava o fim do túnel: podia pertencer a um agente estrangeiro ou estar co-localizado no próprio nó móvel.

Era, portanto, uma instrução de encaminhamento. Não demonstrava posição física, identidade de pessoa, qualidade do enlace, estado atual da lista de visitantes ou entrega à aplicação. A autenticação autorizava a mudança de estado; não transformava a linha do banco em prova de resultado.

O RFC citava um nó ao alcance de mais de um agente estrangeiro. Quando o agente de origem aceitava vínculos simultâneos, interceptava o datagrama dirigido ao endereço de origem, criava uma cópia separada para cada care-of address e a encapsulava no túnel correspondente. O texto reconhecia que IP permite duplicação e que o nó poderia receber cópias múltiplas.

Por isso, dois pacotes iguais não bastavam para concluir replay ou falha. Também não bastavam duas linhas para concluir que ambos os caminhos entregavam. Estado de controle e observação do tráfego continuavam distintos.

Código 0 e código 1 eram sucessos diferentes

Na Registration Reply, o código 0 significava registro aceito. O código 1 também era sucesso, mas informava que vínculos simultâneos não eram suportados. O registro atual da IANA conserva essa diferença.

Se o pedido levava S, o código 0 permitia a convivência do novo vínculo com os antigos. O código 1 aceitava o registro novo sem confirmar a capacidade solicitada. Já o código 135 negava a operação por excesso de vínculos simultâneos.

Um painel que pinta 0 e 1 com o mesmo verde perde a informação necessária para explicar duplicação e substituição. O registro operacional precisa conservar o bit pedido, o código recebido, a lista vigente, os prazos concedidos e o túnel em que cada cópia foi vista.

A saída também era por vínculo

Uma solicitação com prazo zero e care-of address igual ao endereço de origem removia todas as linhas e encerrava o serviço de mobilidade. Com prazo zero e um care-of específico, removia só aquela linha. As demais permaneciam.

Com prazo não nulo, o agente adicionava o endereço. Se S fosse aceito, mantinha os anteriores; caso contrário, apagava-os. Quando uma linha expirava, o agente removia apenas ela e preservava os outros vínculos simultâneos ainda válidos.

Não havia uma nova resposta só porque o prazo terminara. A lista de visitantes do agente estrangeiro podia expirar naturalmente. Esse silêncio não demonstrava que todo o conjunto havia acabado. Da mesma forma, retirar um endereço não demonstrava indisponibilidade total.

Uma retransmissão idêntica também não ganhava prazo novo. Se endereço de origem, care-of address e Identification coincidissem com um registro corrente aceito, a vida não poderia ultrapassar a concessão original. Correlação e proteção contra replay não viravam renovação automática.

O futuro separou identidade de caminho e política de fluxo

Publicado em agosto de 2002, o RFC 3344 substituiu o RFC 3220 na linhagem iniciada pelo RFC 2002. O RFC 5944 o substituiu em 2010 e preservou a capacidade de manter múltiplos registros e copiar cada datagrama para cada care-of ativo. O erratum editorial mantido para atualização e o erratum técnico rejeitado não alteram esse ponto.

No Mobile IPv6, o RFC 3775 distinguiu care-of primário e endereço anterior não primário durante uma transição. O RFC 5648 introduziu Binding Identifiers para administrar endereços múltiplos. O RFC experimental 7629 levou identificadores, vários túneis e política por fluxo ao Mobile IPv4.

O contraste revela o limite do antigo bit S. Ele determinava replicação geral, não seleção de caminho, balanceamento ou teste de saúde. Um vínculo antigo podia ser redundância útil, consumo inútil ou túnel sem entrega. A tabela, sozinha, não decidia.

A memória correta dessa arquitetura é um conjunto de recibos: pedido S, capacidade respondida, endereços aceitos, prazo de cada linha, cópias emitidas e entregas observadas. Ser o endereço mais novo não dava direito de reescrever silenciosamente o passado.

Fontes