Resumo
- No RFC 6626, um Mobile Router pode enviar vários pedidos com Prefix igual a zero. O Home Agent pode alocar alguns, recusar outros com
MOBNET_UNASSIGNEDe escolher um tamanho diferente da dica recebida. - Esses resultados entram no modelo do RFC 5177, em que o código geral já pode indicar sucesso quando apenas um prefixo recebeu encaminhamento. Alocação, registro, anúncio e entrega permanecem comprovantes separados.
Um campo zerado pode ser um pedido, não a ausência de um endereço. O RFC 6626 usa essa convenção para permitir que o Home Agent atribua um Mobile Network Prefix. O Mobile Router pode sugerir o comprimento e repetir a extensão para solicitar várias redes.
A resposta, porém, não é uma cesta indivisível. Cada extensão de reconhecimento pode trazer um prefixo concedido ou um erro. O código 4, MOBNET_UNASSIGNED, foi criado justamente para registrar a incapacidade de atribuir um dos pedidos.
A dica de tamanho não é uma reserva
Quando o Prefix é zero, o comprimento pode ser zero ou um valor escolhido pelo Mobile Router. Para o Home Agent, ele é uma dica. A decisão final sobre o tamanho continua local.
Isso cria três valores que não devem ser confundidos: o tamanho desejado, o tamanho autorizado pela política e o tamanho efetivamente atribuído. Um painel que mostra apenas “alocação concluída” perde a diferença capaz de alterar capacidade, endereçamento interno e planos de crescimento.
O prefixo concedido também não é permanente por ter sido devolvido. Sua vida é igual à entrada do binding cache. Renovação, expiração e nova solicitação formam outra sequência de evidências.
Um resultado positivo pode ser parcial
O RFC 5177, base desse mecanismo, trabalha com dois níveis. Há um reconhecimento para cada prefixo e um código geral de Registration Reply. O código geral é zero se pelo menos um prefixo teve encaminhamento configurado. Somente a falha de todos leva a HA_MOBNET_ERROR.
Assim, três pedidos dinâmicos podem produzir duas alocações, uma MOBNET_UNASSIGNED e ainda uma resposta geral positiva. Mesmo entre as duas alocações, uma tentativa posterior de configurar encaminhamento pode falhar. “O registro funcionou” não informa o total pedido nem o conjunto final.
O denominador operacional deve ser o inventário pretendido: quantos prefixos, de que tamanhos e para quais segmentos móveis.
Identidade para alocação também tem limite
Se a Home Address não for zero, ela pode identificar o cliente para a alocação. Se ela também for zero, o RFC 6626 exige a extensão NAI conforme o Mobile IPv4. Essa identidade permite aplicar política e manter a tabela; não prova, sozinha, direito ilimitado a espaço de endereços.
O documento recomenda conter ataques de esgotamento limitando quantidade e tamanho atribuídos a um Mobile Router. Logo, uma recusa pode representar política de capacidade, não falha de autenticação. Novamente, o código por item importa.
Uma concessão não é alcance
Depois de alocado, o prefixo entra na tabela de registro do RFC 5177 e precisa de encaminhamento para a Care-of Address. A rede de origem ainda pode depender de agregação ou propagação de rota. O túnel precisa existir, as FIBs precisam convergir e os pacotes precisam cruzar o caminho.
Em modo de roteamento dinâmico, o mesmo prefixo não deve ser anunciado também na solicitação Mobile IPv4, pois fontes duplicadas podem criar estados incoerentes. Redes móveis aninhadas acrescentam outra fronteira: o protocolo não resolve loops físicos, e cada nível reduz a MTU útil com novo cabeçalho.
Nada disso invalida a alocação. Apenas impede que ela seja promovida a prova de serviço.
A retirada pode estar na ausência
Para prefixos explícitos já registrados, uma atualização funciona como substituição de conjunto. Se um prefixo anterior não vier na nova solicitação, o Home Agent deve removê-lo e parar de encaminhá-lo. Uma lista incompleta pode, portanto, apagar capacidade antiga enquanto um novo prefixo mantém o código geral verde.
O controle adequado junta os dois lados: novas concessões devem ser reconciliadas com os pedidos; omissões devem ser reconciliadas com retiradas aprovadas. Sem isso, expansão e contração ficam escondidas no mesmo “sucesso”.
Fontes
- https://www.rfc-editor.org/rfc/rfc5177.html
- https://www.rfc-editor.org/rfc/rfc5177.txt
- https://www.rfc-editor.org/info/rfc5177
- https://datatracker.ietf.org/doc/rfc5177/
- https://datatracker.ietf.org/doc/rfc5177/history/
- https://datatracker.ietf.org/doc/rfc5177/references/
- https://www.rfc-editor.org/errata_search.php?rfc=5177
- https://www.iana.org/assignments/mobileip-numbers/mobileip-numbers.xhtml
- https://www.rfc-editor.org/rfc/rfc5944.html
- https://www.rfc-editor.org/rfc/rfc3344.html
- https://www.rfc-editor.org/rfc/rfc3963.html
- https://www.rfc-editor.org/rfc/rfc4885.html
- https://www.rfc-editor.org/rfc/rfc6626.html
- https://www.rfc-editor.org/rfc/rfc6626.txt
- https://www.rfc-editor.org/info/rfc6626
- https://datatracker.ietf.org/doc/rfc6626/
- https://www.rfc-editor.org/rfc/rfc2794.html
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
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
