Anycast

Origem: Wikipédia, a enciclopédia livre.
Visualização do roteamento anycast.

O anycast é uma metodologia de endereçamento e roteamento de rede em que um único endereço IP de destino é compartilhado por dispositivos (geralmente servidores) em vários locais. Os roteadores direcionam os pacotes endereçados a este destino para o local mais próximo do remetente, usando seus algoritmos normais de tomada de decisão, normalmente o menor número de saltos de rede BGP. O roteamento anycast é amplamente usado por redes de distribuição de conteúdo, como hosts da web e DNS, para trazer seu conteúdo mais perto dos usuários finais.

Métodos de endereçamento[editar | editar código-fonte]

Esquemas de roteamento
Unicast

Unicast.svg

Broadcast

Broadcast.svg

Multicast

Multicast.svg

Anycast

Anycast.svg

Existem quatro métodos principais de endereçamento no protocolo de Internet:

  • O endereçamento unicast usa uma associação "um para um" entre um remetente e um destino: cada endereço de destino identifica exclusivamente um único terminal receptor.
  • O broadcast usa uma associação "um para todos". Um único datagrama de um remetente é roteado para todos os pontos de extremidade múltiplos possivelmente associados ao endereço de broadcast. A rede replica automaticamente os datagramas, conforme necessário, para alcançar todos os destinatários dentro do escopo da transmissão, que geralmente é uma sub-rede inteira da rede.
  • O endereçamento multicast usa uma associação "um para muitos de muitos" ou "muitos para muitos de muitos". Os datagramas são roteados simultaneamente em uma única transmissão para vários destinatários. Ele difere do broadcast porque o endereço de destino designa um subconjunto dos, e não necessariamente todos os, nós acessíveis.
  • O endereçamento anycast é uma associação "um para um de muitos". Os datagramas são roteados para qualquer membro de um grupo de receptores potenciais que são, todos, identificados pelo mesmo endereço de destino. O algoritmo de roteamento seleciona um único receptor do grupo com base na métrica de roteamento de menor custo. Na prática, isso significa que os pacotes são roteados para o membro topologicamente mais próximo de um grupo anycast.

História[editar | editar código-fonte]

O primeiro uso documentado do roteamento anycast para balanceamento de carga topológico de serviços conectados à Internet foi em 1989[1] e a técnica foi documentada formalmente na IETF, quatro anos depois, na RFC 1546[2].

Protocolo de internet versão 4 (IPv4)[editar | editar código-fonte]

O anycast pode ser implementado via protocolo de "portal" de fronteira (BGP). Vários hosts (geralmente em áreas geográficas diferentes) recebem o mesmo endereço IP unicast e diferentes rotas para o endereço são anunciadas por meio do BGP. Os roteadores consideram essas rotas alternativas como que para um mesmo destino, embora sejam, na verdade, rotas para destinos diferentes com um mesmo endereço. Como de costume, os roteadores selecionam uma rota de acordo com a métrica de distância em uso (a de menor custo, a menos congestionada, a mais curta). Selecionar uma rota nesta configuração equivale a selecionar um destino.

A armadilha desta abordagem é que uma conexão com um endereço anycast pode falhar porque a rede pode alterar o roteamento de pacotes no meio da conexão devido ao congestionamento ou mudanças na rede, com o resultado de que o destino muda no meio da conexão, embora o novo destino não esteja ciente da conexão e não esteja mantendo o estado de conexão. Essas condições são, normalmente, chamadas de " PoP switch". Com um endereço unicast normal, uma alteração de roteamento não seria um problema, pois isso apenas resulta em uma rota diferente para o mesmo destino eventual. Todos os pacotes em uma conexão, normalmente, não precisam seguir o mesmo caminho. Mas quando o endereço é na verdade um endereço anycast mascarado como um endereço unicast (como neste design), uma alteração de roteamento pode ser uma alteração de destino.

Devido à possibilidade de um "PoP switch" no IPv4, o anycast geralmente é usado com comunicações sem conexão baseadas em UDP, como uma forma de fornecer alta disponibilidade e balanceamento de carga para serviços sem estado. Por exemplo, uma das aplicações mais conhecidas do anycast IPv4 é a do DNS. Isso é adequado para anycast porque é um serviço baseado em UDP que fornece acesso sem conexão à dados de nome de domínio que são replicados em vários servidores sem estado, geograficamente dispersos, com demandas severas de disponibilidade e escalabilidade.

Como o anycast é mais sujeito à erros com protocolos orientados à conexão, como o TCP (onde o destino mantém o estado), é menos comumente usado com esses protocolos. Algumas pilhas IP personalizadas usam métodos proprietários para corrigir protocolos com estado quando necessário,[3] mitigando problemas devido à PoP switches anycast. Esses métodos geralmente envolvem alguma forma de virtualização das funções de rede[4] na forma de reescrita de pacotes, conforme demonstrado pelo AWS HyperPlane[5][6] e pelo Google Maglev[7] e(ou) encapsulamento de pacotes conforme estabelecido por protocolos como o encapsulamento de roteamento genérico e o IPOP.

Protocolo de Internet versão 6 (IPv6)[editar | editar código-fonte]

O anycast é explicitamente suportado no IPv6. A RFC 4291, que cobre a arquitetura de endereçamento IPv6, reserva o identificador de interface 0 dentro de uma sub-rede IPv6 como o endereço anycast do roteador de sub-rede. Além disso, a RFC 2526 reserva um bloco de 128 identificadores de interface em uma sub-rede como endereços anycast.

A maioria dos roteadores IPv6 no caminho de um pacote anycast pela rede não o distingue de um pacote unicast, mas um tratamento especial é necessário por parte dos roteadores próximos ao destino (isto é, dentro do escopo do endereço anycast), pois eles são obrigados à rotear um pacote anycast para a interface, que tem o endereço anycast adequado, mais próxima dentro desse escopo, de acordo com qualquer medida de distância (salto, custo, etc.) que esteja sendo usada.

O método usado no IPv4 para anunciar várias rotas, no BGP, para endereços unicast atribuídos de forma múltipla também funciona no IPv6 e pode ser usado para rotear pacotes para o mais próximo de vários hosts geograficamente dispersos com o mesmo endereço. Esta abordagem, que não depende de roteadores com reconhecimento de anycast, tem os mesmos casos de uso (com os mesmos problemas e limitações) do IPv4.

Aplicações[editar | editar código-fonte]

Com o crescimento da Internet, os serviços de rede têm cada vez mais requisitos de alta disponibilidade. Como resultado, a operação de serviços anycast (RFC 4786) cresceu em popularidade entre as operadoras de rede.[8]

Sistema de nome de domínio (DNS)[editar | editar código-fonte]

Todos os servidores de nomes raiz da Internet são implementados como clusters de hosts usando endereçamento anycast. Todos os 13 servidores raiz (de A à M) existem em vários locais, com 11 deles em vários continentes. Os servidores raiz B e H existem em dois locais nos Estados Unidos da América (E.U.A.).[9][10][11] Esses servidores usam anúncios de endereço anycast para fornecer um serviço descentralizado. Isso acelerou a implantação de servidores raiz físicos (em vez de lógicos) fora dos Estados Unidos. A RFC 3258 documenta o uso de endereçamento anycast para fornecer serviços DNS autorizados. Muitos provedores comerciais de DNS mudaram para um ambiente IP anycast para aumentar o desempenho e a redundância das consultas e também implementar o balanceamento de carga.[carece de fontes?]

Transição IPv6[editar | editar código-fonte]

Na transição de IPv4 para IPv6, o endereçamento anycast pode ser implantado para fornecer compatibilidade IPv6 para hosts IPv4. Este método, 6to4, usa um "portal" (gateway) padrão com o endereço IP 192.88.99.1 (conforme descrito na RFC 3068). Isso permite que vários provedores implementem "portais" (gateways) 6to4 sem que os hosts precisem saber os endereços de "portal" (gateway) de cada provedor individual. Este método foi descontinuado na RFC 7526.

Redes de distribuição de conteúdo[editar | editar código-fonte]

Redes de distribuição de conteúdo podem usar o anycast para conexões HTTP reais com seus centros de distribuição ou para DNS. Como a maioria das conexões HTTP à essas redes solicita conteúdo estático, como imagens e folhas de estilo, elas geralmente têm vida curta e não têm "estado" nas sessões TCP subsequentes. A estabilidade geral das rotas e a ausência de estado das conexões tornam o anycast adequado para esta aplicação, mesmo que ela use o TCP.[carece de fontes?]

Conectividade entre redes anycast e multicast[editar | editar código-fonte]

O ponto de encontro anycast pode ser usado no protocolo de descoberta de fonte multicast (MSDP) e sua aplicação é vantajosa, pois o anycast RP é um recurso intra-domínio que fornece recursos de redundância e compartilhamento de carga. Se vários pontos de encontro anycast forem usados, o roteamento IP automaticamente selecionará o ponto de encontro topologicamente mais próximo para cada fonte e receptor e, assim, forneceria uma rede multicast com os requisitos de tolerância à falhas.[12]

Segurança[editar | editar código-fonte]

O anycast permite que qualquer operador, cujas informações de roteamento são aceitas por um roteador intermediário, sequestre (capture) quaisquer pacotes destinados ao endereço anycast. Embora isso pareça inseguro à primeira vista, não é diferente do roteamento de pacotes IP comuns (ou seja, nem mais menos seguro). Tal como acontece com o roteamento IP convencional, a filtragem cuidadosa de quem pode ou não pode propagar anúncios de rota é crucial para prevenir ataques homem no meio (man-in-the-middle) ou de queda de pacotes (buraco negro). O primeiro pode ser evitado criptografando e autenticando mensagens (e também usando o TLS), enquanto o último pode ser frustrado por roteamento "cebola".

Confiabilidade[editar | editar código-fonte]

O anycast, normalmente, é altamente confiável pois pode fornecer tolerância à falhas automático. Os aplicativos anycast geralmente apresentam monitoramento externo de "pulsação" da função do servidor e retiram o anúncio de rota se o servidor falhar. Em alguns casos, isso é feito pelos servidores reais anunciando o prefixo anycast ao roteador por OSPF ou outro IGP. Se os servidores "morrerem", o roteador retirará automaticamente o anúncio.

A funcionalidade de "pulsação" (heartbeat) é importante porque se o anúncio continuar para um servidor com falha, o servidor atuará como um "buraco negro" para clientes próximos. Este modo de falha é o modo de falha mais sério para um sistema anycast. Mesmo nesse caso, esse tipo de falha só causará uma falha total para clientes que estão mais perto deste servidor do que de qualquer outro e não causará uma falha global.

Mitigação de ataques de negação de serviço[editar | editar código-fonte]

Em ataques de negação de serviço, um host de rede desonesto pode se anunciar como um servidor ''anycast para um serviço de rede vital (para fornecer informações falsas ou simplesmente bloquear o serviço).

As metodologias anycast na Internet podem ser exploradas para realizar ataques DDoS e reduzir sua eficácia. Como o tráfego é roteado para o nó mais próximo, um processo sobre o qual o invasor não tem controle, o fluxo de tráfego DDoS será distribuído entre os nós mais próximos. Portanto, nem todos os nós serão afetados. Este pode ser um motivo para implantar o endereçamento anycast.[13]

A eficácia desta técnica para desviar ataques é questionável, no entanto, porque os endereços unicast (usados para manutenção) podem ser fáceis de obter (pelo menos no IPv6). A agora obsoleta RFC 2373 afirmou que um "endereço anycast não deve ser usado como o endereço de origem de um pacote IPv6". Portanto, o ping em um endereço anycast retornará o endereço unicast do nó mais próximo, já que a resposta deve vir de um endereço unicast. Um invasor pode, então, atacar nós individuais de qualquer local, (ignorando os métodos de endereçamento anycast). Este mesmo método funciona em alguns, mas não em todos, endereços IPv4 anycast.[14] A RFC 2373 também restringia endereços IPv6 anycast apenas à roteadores. No entanto, essas duas restrições foram levantadas na RFC 4291.

A autenticação de transmissões anycast pode resolver este problema.Erro de citação: Etiqueta <ref> inválida; nomes inválidos, por exemplo, demasiados nomes

Ver também[editar | editar código-fonte]

Portal A Wikipédia tem o portal:
  • Internet

Referências

  1. Woodcock, Bill (junho de 1996). «Best practices in anycast routing» [Melhores práticas em roteamento anycast] (PDF) (em inglês). Packet Clearing House. Consultado em 15 de julho de 2021 
  2. Partridge, C.; Mendez, T.; Milliken, W. (novembro de 1993). «Host anycasting service» [Serviço anycasting de host] (PDF). RFC 1546 (em inglês). IETF. Consultado em 15 de julho de 2021 
  3. Prince, Matthew (21 de outubro de 2011). «CEO comment on CloudFlare blog» [Comentário do CEO no blog CloudFlare]. CloudFlare Blog (em inglês). Consultado em 24 de abril de 2021 
  4. «Network functions virtualization (NFV) - Use cases» [Virtualização de funções de rede (NFV) - casos de uso] (PDF). ETSI GS NFV 001 v1.1.1 (em inglês). Outubro de 2013. Consultado em 24 de abril de 2021 
  5. MacCarthaigh, Colm. «HyperPlane». YouTube (em inglês). Consultado em 24 de abril de 2021 
  6. MacCarthaigh, Colm (15 de junho de 2018). «Load balancing at hyperscale» [Balanceamento de carga em hiperescala]. AtScaleConference (em inglês). Consultado em 24 de abril de 2021 
  7. Eisenbud, Daniel. «A fast and reliable software network load balancer» [Um software balanceador de carga de rede rápido e confiável]. Google (em inglês). Consultado em 24 de abril de 2021 
  8. Abley, J.; Lindqvist, K. (dezembro de 2006). «Operation of anycast services» [Operação de serviços anycast] (PDF). RFC 4786 (em inglês). IETF. Consultado em 24 de abril de 2021 
  9. «B-root DNS server home-page» [Página inicial do servidor DNS de raiz B] (em inglês). Consultado em 24 de abril de 2021 
  10. «Report on root name server locations» [Relatório sobre os locais dos servidores de nomes raiz] (em inglês). Packet clearing house. Consultado em 24 de abril de 2021 
  11. «Root server technical operations assn» [Associação de operações técnicas de servidores raiz] (em inglês). root-servers.org. Consultado em 24 de abril de 2021 
  12. «Anycast RP» (em inglês). Cisco Systems. 18 de junho de 2001. Consultado em 24 de abril de 2021 
  13. «ICANN factsheet on root server attack on 6 February 2007» [Ficha informativa da ICANN sobre ataque ao servidor raiz em 6 de fevereiro de 2007] (PDF). Factsheet (em inglês). ICANN. 1 de março de 2007. Consultado em 24 de abril de 2021 
  14. Metz, C. (2002). «IP anycast: Point-to-(any) point communication (sign-in required)» [IP anycast: comunicação ponto a (qualquer) ponto (requer login)]. IEEE. IEEE internet computing (em inglês). 6 (2): 94 à 98. doi:10.1109/4236.991450 

Ligações externas[editar | editar código-fonte]