Águia Tecnologia

Serviços com Sustentabilidade

Automação e Tecnologia da Informação com Sustentabilidade

Restrição devido à baixa resolução de tela.

Saiba mais acessando o menu Sobre.

CGNAT - Carrier Grade NAT

Compartilhamento de endereços no ISP

CGNAT

O esgotamento dos endereços na versão obsoleta do IP (IPv4) levou muitos ISP (Fornecedores de Acesso à Internet) a adotarem técnicas paliativas para evitar o congelamento nas vendas, inicialmente tentou-se a técnica NAT [RFC 3022], que trouxe diversos problemas já abordados em Internet – O colapso, principalmente relacionados à segurança e falhas em aplicações. Esta técnica basicamente altera o conteúdo dos pacotes (endereço IP e porta TCP) para compartilhar um mesmo endereço IP com centenas de equipamentos. Routers residenciais, com ou sem Wi-Fi, e Smartphones na função Tethering utilizam NAT para compartilhar conexões legadas (IPv4).

O IETF elevou o IPv6 (IP versão 6) a Draft Standard em dezembro de 1998 [RFC 2460], indicando que seria o novo Padrão Internet. Foram desenvolvidas várias técnicas de transição permitindo aos equipamentos funcionarem simultaneamente com IPv4 e IPv6, tornando a transição transparente ao usuário, IPv4 passa a ser utilizado apenas para Aplicações (sites e serviços) não atualizados para IPv6. Destaco, aqui, Carrier Grade NAT (NAT à Nível de Operadora ou de ISP) - CGNAT, também conhecida por LSN, CGN, CGN NAT, CG-NAT444, NAT444, dupla NAT, ou NAT na Operadora, amplamente utilizado no Brasil.

Funcionamento do CGNAT

A CGNAT altera o conteúdo dos pacotes IPv4 no ISP para permitir o compartilhamento de endereços, de forma análoga à NAT. A diferença principal entre elas é onde são executadas, a NAT é executada no CPE (roteador Wi-Fi, Smartphone do usuário) e, o CGNAT, de forma centralizada no ISP (fornecedor de acesso, operadora). A NAT utiliza endereços de uso privado, o CGNAT endereços do Shared Address Space.

Endereços de Uso Privado [BCP5, RFC1918]:

  • 10.0.0.0/8
    10.0.0.1 a 10.255.255.255
    Aproximadamente 16 milhões de endereços
  • 172.16.0.0/12
    172.16.0.0 a 172.31.255.255
    Aproximadamente 1 milhão de endereços
  • 192.168.0.0/16
    192.168.0.0 a 192.168.255.255
    Bloco de 65.536 endereços

Shared Address Space [BCP153, RFC6598]:

  • 100.64.0.0/10
    100.64.0.0 a 100.127.255.255
    Aproximadamente 4 milhões de endereços

Conforme descrito na RFC 6264 (junho de 2011):

  • Rede legada (IPv4)
    • CPE cria uma rede interna com endereços de uso privado [RFC 1918];
    • CPE entrega a cada dispositivo um endereço privado;
    • CPE recebe um endereço (Shared Address Space [BCP 153]) do ISP;
    • CPE compartilha o endereço com NAT;
    • ISP executa outra NAT para compartilhar o mesmo IP com centenas de CPEs.
  • Cada CPE pode compartilhar um mesmo endereço com centenas de dispositivos e o ISP compartilhará um único endereços com centenas de CPEs, resultando em milhares com um mesmo endereço na Internet.
  • Rede IPv6
    • CPE recebe um bloco (vários endereços) do ISP;
    • CPE entrega um endereço do bloco para cada dispositivo;
  • Cada dispositivo utiliza um endereço do bloco recebido para acessar a Internet, sem a necessidade de NAT. O mínimo que o ISP entrega é uma rede entre /64 e /48, para que o CPE permita a configuração dos dispositivos.
RFC 6264
RFC 6264
Vantagens no uso da CGNAT
  • Protela o impacto causado pelo esgotamento de endereços;
  • Não exige a substituição imediata de CPE legado;
  • Prolonga o uso de equipamentos arcaicos na rede do ISP;
  • Não exige atualização da maioria dos serviços na rede do ISP;
  • Economia com treinamento, tecnologia antiga e conhecida.
Desvantagens no uso da CGNAT
  • Fere o princípio de comunicação fim a fim da Internet;
  • Acarreta mal funcionamento em várias aplicações;
  • Fere o princípio de neutralidade da rede;
  • Cria vários problemas de segurança, difíceis de contornar;
  • Altíssimo custo, comparado às técnicas de transição ao IPv6;
  • Procrastina o inevitável, que é a transição ao IPv6.

A comunicação fim a fim, ou comunicação direta entre dois equipamentos, sem interferência ou alteração nos dados transmitidos, é um dos princípios fundamentais da Internet. Técnicas que foram desenvolvidas para restabelecer parcialmente esta comunicação, como servidores STUN, uPnP e outras não funcionam com CGNAT, impedindo o funcionamento adequado de Consoles de jogos (XBox), Voz sobre IP (SIP), Geolocalização, monitoração de câmeras de segurança e outros, muitos essenciais. CGNAT, também, impede o funcionamento do mecanismo de segurança IPsec.

A concentração excessiva de conexões pelo mesmo equipamento (CGNAT) acarreta redução de desempenho em muitas aplicações e serviços, principalmente em transferência de arquivos, conferências (voz e/ou vídeo) e video streamming (Netflix, Youtube), além de tornar rede vulnerável, pois ela fica mais atraente para ataques de DDoS (negação de serviço) e facilita o Spoofing (falsificação de identidade). Diversas redes possuem sistemas para impedir Spam, realizando o bloqueio do endereço IP, o que realiza o bloqueio de todos os que o compartilham.

A CGNAT, seja ferindo o princípio da comunicação fim a fim, ou através da degradação que ocasiona em diversas aplicações e serviços, também fere o princípio da neutralidade da rede, princípio que garante a todos os dados trafegados serem tratados da mesma forma, sem discriminação.

Os equipamentos que executam este mecanismo precisam de elevado poder de processamento e memória para garantir um desempenho aceitável, tornando seus custos elevadíssimos em relação a outros equipamentos de rede que possuem suporte ao IPv6, que é o padrão da Internet, substituto daquele que o CGNAT pretende manter na rede. O CGNAT é inviável economicamente e fatalmente seus custos serão repassados aos usuários da Internet.

O compartilhamento de endereços gera uma falha de segurança gravíssima, a dificuldade de identificação de atos ilícitos, tendo em vista que centenas de clientes utilizam o mesmo endereço IP ao mesmo tempo. A única solução para esta falha seria o log (registro) da porta TCP na origem (ISP) e destino da conexão (Provedor de aplicação - site de conteúdo), além do endereço IP e momento de acesso. Entretanto, a Lei Federal 12.965/2014 determina que sejam registrados no provedor de aplicação somente data e hora de uso de uma determinada aplicação de internet a partir de um determinado endereço IP (Art. 5º, VIII), além de proibir o ISP de registrar a aplicação (log da porta TCP permite esta identificação), ou seja, o CGNAT em qualquer rede brasileira fatalmente promoverá a impunidade de criminosos na Internet, produz insegurança jurídica em torno da Lei 12.965.

O CGNAT é um mecanismo que pode procrastinar a transição do ISP ao IPv6, uma vez que funciona mesmo sem IPv6 na rede, pode ser usado irregularmente como simples "muleta técnica". O uso de tunnel broker seria uma forma de usuários finais obterem acesso IPv6 em ISP que ainda não atualizou a rede, mas a tecnologia de tunnel broker não funciona com CGNAT, pois exige endereço IP público.

Os requisitos técnicos para a prestação de serviços de Internet no Brasil, elencados pelo Decreto Federal 8.771/2016, obrigam os fornecedores a seguirem as diretrizes estabelecidas pelo Comitê Gestor da Internet - CGIbr, utilizando-se apenas de medidas técnicas compatíveis com os padrões internacionais (RFC: STD e BCP). O CGI.br orienta para uso de CGNAT apenas na impossibilidade de uso das várias técnicas para a transição para o IPv6.

Os vídeos a seguir foram feitos pelo NICbr, que implementa as decisões e projetos do CGI.br.

Técnicas de Transição IPv6 - parte 2

Problemas e implicações do uso de CGNAT na Internet


Referências:

O Livro do IETF = El libro del IETF – São Paulo: Comitê Gestor da Internet no Brasil, 2014

Editor: Paul Hoffman.

Organizadores: Julião Braga, Lisandro Zambenedetti Granville, Christian O’Flaherty e Antônio Marcos Moreiras.

TCP/IP – Teoria e Prática – Lisboa, Portugal: FCA - Editora de Informática, Lda., 2012

Autores: Fernando Boavida e Mário Bernardes.

Site Consultor Jurídico

Entrave tecnológico provoca impasse sobre Marco Civil e anonimato , 17 de dezembro de 2016.

Internet Assigned Numbers Authority - IANA

IANA IPv4 Special-Purpose Address Registry - Acesso em 10/02/2019.

Internet Engineering Task Force - IETF:
RFC 791 (STD 5) Internet Protocol, 1981.
RFC 793 (STD 7) Transmission Control Protocol, 1981.
RFC 8200 (STD 86) Internet Protocol, Version 6 (IPv6) Specification, 2017.
RFC 1918 (BCP 5) Address Allocation for Private Internets, 1996.
RFC 2026 (BCP9) The Internet Standard Process – Revision 3, 1996.
RFC 6598 (BCP153) IANA-Reserved IPv4 Prefix for Shared Address Space, 2012.
RFC 6888 (BCP127) Commom Requirements for Carrier-Grade NATs (CGNs), 2013.
RFC 7857 (BCP127) Updates to Network Address Translation (NAT) Behavioral Requirements, 2016.
RFC 2775 – Internet Transparency, 2000.
RFC 2993 – Architetural Implications of NAT, 2000.
RFC 3022 – Traditional IP Network Address Translator (Traditional NAT), 2001.
RFC 3027 – Protocol Complications with the IP Network Address Translator, 2001.
RFC 3053 – IPv6 Tunnel Broker, 2001.
RFC 6264 – An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition, 2011.
RFC 6269 – Issues with IP Address Sharing, 2011.
RFC 7021 – Assessing the Impact of Carrier-Grade NAT on Network Applications, 2013.

Palácio do Planalto (Acesso em 28/05/2019):
Lei Federal 8.078, de 11 de setembro de 1990 - Código de Defesa e Proteção ao Consumidor
Lei Federal 12.965, de 23 de abril de 2014 - Marco Civil da Internet no Brasil.
Decreto Presidencial 8.771, de 11 de maio de 2016.