Resumo

  • O LISP só entrega quando a relação EID-RLOC foi registrada por um ETR autorizado, resolvida pelo Mapping System, mantida dentro do TTL no Map-Cache, submetida a Priority e Weight, alcançada pelo underlay e completada pelo ETR no site de destino.
  • David Meyer é um dos coautores das gerações original e atual do plano de dados. Sua contribuição ilumina a passagem de uma separação elegante para um sistema coletivo de estado temporário; ela não o transforma em inventor único nem o EID em direito de propriedade.

Um endereço estável, uma rota que precisa ser renovada

Há uma sedução na ideia de conservar um endereço enquanto a rede muda ao redor dele. Aplicações e políticas internas não precisam aprender um novo nome a cada conexão de provedor. A topologia, por sua vez, pode usar endereços próprios e agregáveis. O que parece liberdade do endereço, porém, é dependência de uma nova infraestrutura de informação.

O RFC 4984 registra o workshop do IAB de 2006 sobre escala de roteamento. Os participantes associaram parte da pressão sobre a tabela global ao uso da mesma numeração para identificar e localizar. Uma separação parecia necessária, mas o encontro não definiu sua arquitetura. O relatório expressava as posições do workshop, não uma solução oficial do IAB.

O RFC 9299 apresenta a resposta arquitetural do LISP. EID e RLOC têm a mesma aparência de um endereço IPv4 ou IPv6, mas pertencem a espaços de significado distintos. O EID identifica uma ponta sem carregar localização interdomínio. O RLOC descreve um ponto de conexão topológico no underlay. Um Mapping System mantém a relação, e roteadores de túnel encapsulam o pacote para o local escolhido.

O número persistente não leva consigo uma bússola. Para encaminhá-lo, cada remetente depende de uma resposta externa e temporária.

A sequência que o slogan não mostra

O RFC 9300 exige que um EID usado na Internet pública seja único e venha de um prefixo associado ao site. Esse requisito não autentica uma pessoa, não estabelece propriedade, não promete portabilidade entre empresas e não prova que o EID esteja registrado no momento. Unicidade evita colisões; operação exige outras evidências.

Primeiro, o ETR associa o EID-Prefix a um ou mais RLOCs. Ele envia um Map-Register ao Map-Server. O servidor deve conhecer quais prefixos aquele ETR pode anunciar, e os dois precisam de um segredo previamente configurado para derivar a autenticação. O RFC 9301 trata a ausência dessa conferência como abertura para sequestro simples do prefixo.

Depois, um ITR procura o EID de destino por prefixo mais longo em seu Map-Cache local. Um acerto devolve um Locator-Set. Uma falha inicia um Map-Request por meio do Map-Resolver. Enquanto espera, o operador escolhe entre descartar e armazenar pacotes. Esse detalhe aparentemente pequeno define a experiência de indisponibilidade.

A resposta possui TTL. Zero remove a entrada imediatamente; um valor especial delega a duração ao receptor. O cache guarda também informações de alcance. Portanto, o registro autoritativo pode ter mudado sem que todos os ITRs ativos já usem a nova relação.

Em seguida, a lista de RLOCs precisa de decisão. O menor Priority vence; 255 impede uso para encaminhamento. Em igualdade de prioridade, Weight distribui a carga. Uma alteração de peso muda o caminho real sem tocar no EID. O mapa é ao mesmo tempo diretório e política de engenharia de tráfego.

Por fim, o underlay precisa levar o pacote externo ao RLOC. O ETR retira o cabeçalho LISP e entrega o pacote interno dentro do site. Uma relação correta pode apontar para um local sem rota. Um local alcançável pode receber o invólucro e falhar no último trecho. A existência do identificador fica no início, não no fim, da prova.

Respostas que envelhecem em velocidades diferentes

O Map-Register é renovado periodicamente e pode expirar quando deixam de chegar mensagens válidas. Um Map-Reply sem localizadores preserva o motivo: EID sem registro, negação por política ou falha de autenticação. A ação pode mandar encaminhar nativamente, consultar de novo, manter sem encapsular ou descartar. Operação madura não resume esses resultados a “não encontrado”.

Quando a relação muda, o Solicit-Map-Request pode pedir aos ITRs que já a armazenam que façam nova consulta. O mecanismo é seletivo e sujeito a limites de taxa. Quem não guarda aquela entrada não deve produzir tráfego de atualização. Não existe um botão central que reescreva instantaneamente todos os caches.

O RFC 9302 deixa o problema explícito em ambientes fechados e confiáveis. Seu Map-Version opcional usa doze bits e avança quando se adiciona ou remove RLOC, quando Priority ou Weight muda ou quando muda o alcance local. Como o espaço numérico dá a volta, uma versão muito antiga pode parecer nova; é preciso aguardar ao menos o TTL anterior ou confirmar que o tráfego ativo adotou o estado recente.

Na Internet pública, o RFC 9300 proíbe usar Map-Versioning, gleaning, Locator-Status-Bits e Echo-Nonce como atalhos de atualização ou alcance de RLOC. O plano de controle deve fornecer a evidência. Uma indicação rápida só é segura dentro do domínio de confiança para o qual foi desenhada.

O mapa tem uma política de segurança

O RFC 9301 assume um Mapping System seguro e confiável, ETRs com relação de confiança preconfigurada e conhecimento dos EIDs que cada um pode anunciar. Como criar chaves e direitos fica fora de escopo. A especificação começa depois de uma instituição decidir quem fala por um prefixo.

O RFC 9303 define LISP-SEC para autenticar a origem, proteger integridade, evitar replay e verificar a autorização de alegações sobre EID-Prefix. Sem isso, um mapa falso pode desviar o tráfego ou reivindicar um bloco maior. Mesmo LISP-SEC pressupõe que o Mapping System leve a solicitação ao ETR correto e que o Map-Server valide o direito de registro. Segurança protege a relação, não transforma o EID em credencial.

Persistência também amplia a superfície de privacidade. Um EID duradouro ligado a RLOCs sucessivos pode revelar uma trajetória topológica. A continuidade que reduz renumeração pode facilitar correlação.

Meyer como fio histórico, não como proprietário

Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis e o editor Albert Cabellos assinam o RFC 9300. Meyer também participou do RFC 6830 original. O percurso torna possível acompanhar o amadurecimento do LISP, mas a autoria e a autoridade continuam coletivas: IETF, implementadores, operadores do Mapping System, sites e redes de trânsito seguram partes diferentes.

A página histórica da ONUG registra passagens de Meyer por Cisco e Brocade, sua participação no IAB e na comunidade NANOG e o trabalho com RouteViews na Universidade do Oregon. É uma fonte datada, não um currículo atual. Ela situa uma preocupação que atravessa seus projetos: um estado de controle só serve à operação quando pode ser observado e testado.

Já existe uma matéria sobre Meyer dedicada a RouteViews, RPSL e OpenDaylight. O mecanismo aqui é outro. Não se discute a abertura pública do controle, mas a custódia de uma afirmação específica: este EID deve ser alcançado por estes RLOCs, por este tempo, sob esta autorização.

O RFC 7215 mostra por que a frase precisa de tantas condições. Seu guia Experimental de migração manda conferir plataforma, configuração, MTU, alocação do prefixo, alcance dos RLOCs, registro e chave, caches de proxy, políticas BGP, visibilidade externa e tráfego. Algumas técnicas pertencem ao cenário de transição de 2014. A disciplina de prova permanece: suporte não é configuração; configuração não é registro; registro não é entrega.

O resultado mais preciso não é que o endereço ficou livre da localização. O EID ganhou continuidade porque uma comunidade aceitou manter a localização em outro lugar, com autorização e prazo. O mapa é parte do serviço.

Fontes