Resumo
- O RFC 5149 define uma opção de mobilidade para seleção de serviço em Binding Updates do Mobile IPv6.
- A opção identifica o contexto solicitado; ela não concede o serviço.
- Só pode haver uma opção por atualização, depois de MN-NAI quando presente e antes das opções de autorização ou autenticação.
- O tipo 20 carrega um identificador não vazio de 1 a 255 octetos, em UTF-8 normalizado por NFKC.
- A unicidade é exigida apenas entre os agentes locais nos quais aquele nó pode se registrar, não em escala mundial.
- O agente local autentica o nó e verifica separadamente se a assinatura autoriza o serviço identificado.
- A negativa usa o status 151,
SERVICE_AUTHORIZATION_FAILED. - Uma mudança de serviço exige nova autorização e uma falha pode apagar o binding anterior.
- A seleção pode alterar endereço, prefixo, rota, firewall, segurança, política e QoS sem provar a aplicação de nenhum deles.
- Um nó correspondente sem o mesmo conhecimento de catálogo deve ignorar a opção silenciosamente.
- ESP pode ocultar o identificador no trânsito, mas não comprova direito de uso nem entrega.
- Registro, aplicação de política, caminho de dados, cobrança e resultado do usuário exigem evidências distintas.
O padrão reduz configuração, não incerteza
O mecanismo foi criado porque uma identidade móvel pode ter direito a mais de um contexto: acesso empresarial, domínio privado, serviço separado ou tratamento específico de política e qualidade. Quando o identificador está ausente, o agente local não fica sem semântica; ele interpreta a atualização como pedido de Internet simples.
Essa escolha de projeto é útil. Um dispositivo não deveria precisar conhecer um código proprietário apenas para tentar obter conectividade básica. Por isso, o RFC recomenda fortemente que operadores autorizem o serviço padrão. A mesma seção, porém, preserva a possibilidade de um assinante não ter esse direito. “Padrão” descreve a pergunta feita ao sistema de autorização; não antecipa a resposta.
Uma telemetria que registra apenas “selector absent” não pode concluir “Internet available”. Precisa do resultado de autenticação, da autorização do perfil, do binding resultante, da instalação de política e de uma prova de caminho. O silêncio do campo reduz informação explícita, não reduz a necessidade de evidência operacional.
Um rótulo delimitado entra na atualização
Quando há seleção, o contrato de fio é estreito. O valor do tipo 20 tem de conter entre 1 e 255 octetos, usar UTF-8 e ser normalizado por NFKC. No máximo um pode aparecer em cada Binding Update. Se MN-NAI estiver presente, a seleção vem depois dele e antes de opções relacionadas a autorização ou autenticação.
A posição permite que os mecanismos de proteção incluam o serviço solicitado. Ela não converte o rótulo em credencial. O agente local ainda precisa autenticar o nó e consultar a assinatura para decidir se aquele contexto é permitido. Um identificador parecido com domínio continua sendo um nome de catálogo, não evidência de controle de DNS, propriedade global ou aceitação por terceiros.
Nem sequer se exige uma raiz mundial de nomes. O valor precisa ser único apenas entre os agentes locais nos quais aquele nó móvel está autorizado a registrar-se. Exportá-lo para painéis, faturamento ou parceiros sem registrar esse escopo pode criar colisões semânticas que o protocolo jamais prometeu impedir.
O status 151 também pode encerrar o que funcionava
Se o agente local não autoriza o serviço solicitado, nega o registro com status 151, SERVICE_AUTHORIZATION_FAILED. Isso parece um resultado bem contido até que a atualização represente uma troca. Serviços diferentes podem exigir Home Addresses ou Home Network Prefixes diferentes, além de políticas distintas.
Numa mudança, o agente deve repetir a autorização. Em caso de falha, ele nega a atualização e remove qualquer binding relativo ao endereço ou prefixo existente. O nó móvel que recebe o status 151 também elimina o binding correspondente. O RFC recomenda inclusive desregistrar o serviço atual antes de registrar outro.
A sequência transforma uma escolha de catálogo em uma migração com risco. A recusa do novo contexto não demonstra a sobrevivência do antigo. O operador precisa correlacionar estado anterior, decisão de remoção, nova alocação, rota restaurada e sessão do usuário. Um código correto pode acompanhar uma interrupção real.
Seis superfícies de política, seis recibos ausentes
Uma seleção aceita pode orientar endereço ou prefixo, roteamento de saída, firewall, política de segurança, outras políticas e QoS. O Binding Acknowledgement confirma uma etapa no agente local. Ele não confirma que o compilador produziu a configuração esperada, que o ponto de aplicação a carregou ou que o tráfego obteve o tratamento anunciado.
Um prefixo alocado pode não ter caminho de retorno. Uma regra presente no controlador pode faltar no plano de dados. Uma classe de QoS pode existir sem medição. DNS, rede externa, aplicação e cobrança estão ainda mais distantes do campo original. Cada camada deve emitir sua própria leitura ou ser testada diretamente.
O RFC também adverte que serviços em domínios administrativos separados podem aplicar filtragem agressiva de entrada e saída. Selecionar um serviço pode restringir o acesso simultâneo a outro. Assim, uma luz verde no registro pode coexistir com um destino inacessível ou com a perda de uma sessão anteriormente válida.
A fronteira administrativa limita a interpretação
O nó móvel normalmente não deve enviar a opção ao nó correspondente, pois não pode presumir que ele conheça o catálogo do agente local. Sem conhecimento compartilhado, o correspondente deve ignorá-la silenciosamente. A ausência de reação é, nesse caso, comportamento especificado, não prova de falha.
Em uma implantação sob a mesma administração, as duas pontas podem compartilhar nomes e aplicar tratamento por serviço. Mesmo aí, nome comum não significa estado comum. Revisões de catálogo, dados de assinatura, caches, geradores de política e equipamentos de encaminhamento podem divergir. A afirmação “ambos reconheceram o serviço” precisa de dois recibos; a afirmação “o serviço funcionou” precisa ainda do caminho e da aplicação.
Se a seleção revelar informação sensível, o RFC recomenda ESP em modo transporte com criptografia não nula. A confidencialidade protege o fato de observadores, mas não torna verdadeiro o cadastro que o originou. Do mesmo modo, autorização válida não prova que o identificador ficou confidencial.
As atribuições IANA — tipo 20 e status 151 — estabelecem coordenação documental. Não inventariam suporte num produto nem demonstram interoperabilidade em produção. O RFC 3775 foi posteriormente substituído pelo RFC 6275; referências posteriores mostram linhagem técnica, não um inventário de redes ativas.
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