A (RFC) 6888 define o -grade (CGN, muitas vezes escrito ) como uma função baseada em NAT que divide um endereço IPv4 entre vários assinantes, e acrescenta: "A CGN is not managed by the subscribers", o assinante não o administra (RFC 6888, seção 2). O nome indica um lugar, não uma qualidade: "the term 'carrier-grade' has nothing to do with the quality of the NAT", não indica qualidade (seção 2). Você esbarra nele quando o endereço de wide area network () do roteador começa com 100.64, quando duas casas não jogam a mesma partida ou quando endereço e horário já não apontam uma pessoa. Depois da leitura, você consegue dizer o que a RFC 6888 exige, nomear o que quebrou nos testes, listar o que um pedido de atribuição respondível traz, calcular volumes de logging e um port block, comparar o NAT444 com as alternativas e verificar a sua própria conexão.
Duas camadas de NAT e o espaço entre elas
Cada assinante recebe um endereço privado, um NAT na rede do Internet service provider () o traduz, e um segundo NAT na borda do cliente forma duas camadas (RFC 6888, seção 1). A camada de dentro é o roteador de casa fazendo o que o NAT explicado descreve; a de fora é o CGN, "also called NAT444 CGN or Large Scale NAT", nomes alternativos (RFC 6264, seção 1).
O link entre o CGN e o customer premises equipment () precisa de endereços próprios: "The Shared Address Space address range is 100.64.0.0/10", a faixa reservada (RFC 6598, seção 7), com 4.194.304 endereços, de 100.64.0.0 a 100.127.255.255. Ela é distinta do espaço privado da RFC 1918, que se torna inseguro ali quando "subscribers provide their own CPE and number their own internal network", CPE e rede do próprio assinante (seção 3). Endereços compartilhados não podem cruzar a fronteira entre provedores nem aparecer no DNS externo (seções 4 e 6), e a Internet Assigned Numbers Authority () marca o bloco como não alcançável globalmente (IANA, IPv4 Special-Purpose Address Registry), a coluna que o artigo das faixas explica.
Por que os endereços acabaram
O pool central se esgotou em 2011, e os regional Internet registries (RIRs) vieram depois, cada um na sua data:
| Registro | Evento | Data |
|---|---|---|
| Number Resource Organization (NRO), pelo pool central | free pool "now fully depleted", totalmente esgotado (NRO) | 3 de fevereiro de 2011 |
| Asia Pacific Network Information Centre (APNIC) | entra em vigor a política do último /8 (APNIC) | 15 de abril de 2011 |
| Latin American and Caribbean Internet Address Registry () | resta um /10 (NRO); último bloco reservado (LACNIC) | 10 de junho de 2014; 28 de agosto de 2020 |
| American Registry for Internet Numbers (ARIN) | entrega os últimos endereços do free pool (ARIN) | 24 de setembro de 2015 |
| RIPE Network Coordination Centre (RIPE NCC) | último /8 em 2012; estoque esgotado (RIPE NCC) | 25 de novembro de 2019 |
| African Network Information Centre (AFRINIC) | fase 2 do esgotamento, ainda vigente na leitura (AFRINIC) | desde 13 de janeiro de 2020 |
O RIPE NCC pôs lado a lado o mercado de transferências e o CGNAT e concluiu que "neither one solves the underlying problem, which is that there are not enough IPv4 addresses for everyone", nenhum resolve a falta (RIPE NCC, 25 de novembro de 2019). A história completa está em Como funcionam os endereços IPv4.
O que a RFC 6888 exige de um carrier-grade NAT
A RFC 6888 se apoia nos documentos genéricos de NAT: o REQ-1 obriga o CGN a cumprir os requisitos de comportamento da RFC 4787 para UDP e da RFC 5382 para TCP (RFC 6888, seção 3). O endpoint-independent mapping vem, portanto, da RFC 4787: "A NAT MUST have an 'Endpoint-Independent Mapping' behavior", mapping independente do destino (RFC 4787, seção 4.1). O que a RFC 6888 acrescenta é isto:
| Requisito | Força | O que pede | Seção |
|---|---|---|---|
| REQ-2 | MUST | address pooling "Paired": um só endereço externo para todas as sessões do assinante (a RFC 4787 apenas recomenda) | 3 |
| REQ-4 | MUST | um limite configurável de portas externas por assinante, por equidade | 3 |
| REQ-7 | RECOMMENDED | endpoint-independent filtering, do qual alguns jogos e aplicações dependem | 3 |
| REQ-8 | SHOULD | não reutilizar uma porta liberada antes de 120 segundos, inclusive depois de queda ou failover | 3 |
| REQ-9 | MUST | um protocolo que dê ao assinante controle sobre os seus mappings, de preferência o Port Control Protocol (PCP) | 3 |
| REQ-11 | MUST e SHOULD | na cota: descartar o pacote, enviar Internet Control Message Protocol () Host Unreachable, nunca apagar mappings existentes | 3 |
| REQ-12 | SHOULD NOT | registrar endereços ou portas de destino, porque "Destination logging at the CGN creates privacy issues", risco à privacidade | 4 |
| REQ-13 a REQ-15 | SHOULD | maximizar o uso de portas, minimizar o volume de log, tornar as portas difíceis de adivinhar | 5 |
Os três últimos entram em conflito: "A CGN implementation's choice of port allocation scheme optimizes to satisfy one requirement at the expense of another", um ganho custa outro (RFC 6888, seção 5). Acima das 1.024 portas de sistema, um endereço tem 64.512; uma divisão estática dá 1.008 portas para cada um de 64 assinantes e 64 para cada um de 1.000. Um worm num único aparelho poderia esgotar o endereço de todos, o que o limite do REQ-4 impede (RFC 6269, seção 5.1).
O que quebra para o assinante
A RFC 7021 relata testes de NAT444 em 2010 e de NAT444 e Dual-Stack Lite () em 2011 (RFC 7021, seção 1). O básico funcionou: "basic services such as email and web browsing worked normally and as expected", o básico funcionou (seção 3). Jogo peer-to-peer entre duas casas atrás do mesmo CGN falhou: os dois consoles tentaram a mesma porta no mesmo endereço (seção 3.1). Chamadas Session Initiation Protocol () sem proxy falharam, o seeding de BitTorrent falhou, e o mesmo aconteceu com um servidor File Transfer Protocol () em casa: "FTP sessions to servers located inside the home (e.g., behind two layers of NAT) failed", servidor em casa falhou (seção 3.1). Em 2010, os túneis IPv6 6to4 e falharam ou degradaram muito (seção 3). Remote desktop, virtual private network (), ping e traceroute passaram; uma webcam falhou (seção 5.1). Um console avisou "Your NAT type is moderate", palavras dele, não um termo das normas.
Uma sessão de remote desktop aberta de casa funciona; um servidor em casa não, já que "inbound connections to well-known port numbers will not work in the general case", sem entrada em portas conhecidas (RFC 6269, seção 5.2.2), e um port forwarding também precisa ser aberto no CGN (seção 5.2.1). Os vizinhos pagam junto: "penalty box solutions to service abuse simply will not work", bloqueio por endereço falha (seção 13.1), pôr o endereço de um spammer numa blacklist restringe quem o divide (seção 13.3), e a geolocalização encontra o CGN, não a casa (seção 7). Um ICMP Packet Too Big forjado pode reduzir a maximum transmission unit () que um servidor guarda para todos no endereço (seção 10). A RFC 6888 se defende com limite de portas, ingress filtering contra CPEs falsificados e portas difíceis de adivinhar (RFC 6888, seções 3, 5 e 7).
Atribuição: o endereço virou uma tupla
Quando o endereço é compartilhado, "the IPv4 address no longer uniquely identifies a subscriber", não identifica mais um único assinante (RFC 6269, seção 12). O pedido precisa disto: "The legal request should include the information: [Source IP address, Source Port, Timestamp]", endereço, source port e timestamp. Sem a porta registrada no servidor nem os destinos registrados no NAT, o provedor "would need to disclose the identity of all subscribers who had active sessions on the NAT during the time period in question", entregaria todos os assinantes ativos. Os relógios precisam concordar, porque um pequeno desvio entre servidor e CGN gera dúvida sobre quem usava a porta; os mappings ficam guardados de 6 a 12 meses, conforme a jurisdição (seção 12).
A metade do servidor é a RFC 6302: registrar a source port e, em Coordinated Universal Time (), "A timestamp, RECOMMENDED in UTC, accurate to the second, from a traceable time source", ao segundo (RFC 6302, seção 2). Com servidores assim, o CGN não precisa registrar destinos (RFC 6888, seção 4).
Em 17 de outubro de 2017, a Europol escreveu que "it has become technically impossible for internet service providers to comply with legal orders to identify individual subscribers", ordens de identificação impossíveis de cumprir, o que "may lead to innocent individuals being wrongly investigated by law enforcement", inocentes investigados (Europol, 17 de outubro de 2017); o comunicado fala em CGN em 90% do acesso móvel e 50% do fixo, enquanto o Internet Organised Crime Threat Assessment (IOCTA) 2017 dá 90% das operadoras móveis e 38% dos provedores fixos em 2016. O IOCTA recomenda examinar "source port number logging or limiting either the use of CGN or the number of subscribers behind each IPv4 address", registrar a porta ou limitar o CGN (Europol, IOCTA 2017, páginas 62 a 64).
No Brasil, o artigo 13 da Lei 12.965/2014, o Marco Civil da Internet, diz que "cabe ao administrador de sistema autônomo respectivo o dever de manter os registros de conexão, sob sigilo, em ambiente controlado e de segurança, pelo prazo de 1 (um) ano" (Lei nº 12.965/2014, art. 13). O artigo 5º, inciso VI, define o registro pela "data e hora de início e término de uma conexão à internet, sua duração e o endereço IP utilizado pelo terminal": horários, duração e endereço IP, sem source port. A entrega "deverá ser precedida de autorização judicial" (art. 13, § 5º).
A aritmética do logging
A RFC 7422 mediu linhas de log de cerca de 150 bytes no NAT444 e 175 no DS-Lite, e relata cerca de 33.000 conexões por domicílio por dia (RFC 7422, seção 1). Registrar cada conexão custa então, recalculado:
| Escopo | Conta | Resultado |
|---|---|---|
| um assinante, um dia | 33.000 x 150 B | 4,95 MB |
| um assinante, 30 dias | 4,95 MB x 30 | 148,5 MB |
| um milhão de assinantes, 30 dias | 148,5 MB x 1.000.000 | 148,5 TB |
| um milhão de assinantes, um ano | 148,5 TB x 12 | 1,78 PB |
| fluxo de log para 50.000 assinantes | 50.000 x 4,95 MB x 8 / 86.400 s | 22,9 Mbit/s |
| um assinante DS-Lite, um dia | 33.000 x 175 B | 5,775 MB |
A RFC 7422 arredonda para "approximately 150 terabytes of log data per month, or 1.8 petabytes per year", 150 TB por mês e 1,8 PB por ano (seção 1). Os port blocks mudam a unidade: "Logs are generated only when blocks are allocated or deallocated", log só por bloco, o que divide a geração de log pelo tamanho do bloco (RFC 7768, seção 2). Para 20.000 assinantes em 60 dias, a RFC 7768 relata 42,5 TB por sessão contra 40,6 GB por bloco (seção 1), 1.047 para 1. Com 33.000 conexões por dia, blocos de 256 portas pedem no máximo 128,9 linhas, e blocos de 2.048 portas, 16,1. O preço é eficiência: o bloco fica reservado mesmo que as portas não sejam usadas (RFC 9313, seção 4.7).
Mapping determinístico: uma função no lugar do log
A RFC 7422 transforma o bloco numa função do endereço interno, com inversa: "Internal IP Address = function 2 (External IP Address, Port Number)", a inversa (RFC 7422, seção 2). O CGN tira as portas reservadas, divide o resto pela compression ratio C mais um fator de pool dinâmico D e registra só os blocos de excesso. No exemplo da seção 2.3, recalculado, 14 endereços internos dividem 192.0.2.1 com D = 2; então C + D = 16 e cada um recebe (65.536 - 1.024) / 16 = 4.032 portas:
inside address outside address and ports
198.51.100.1 192.0.2.1:1024-5055
198.51.100.2 192.0.2.1:5056-9087
198.51.100.14 192.0.2.1:53440-57471
dynamic pool 192.0.2.1:57472-65535 (8,064 ports = 2 x 4,032)
Com máximo de 5.040, cada assinante pode tomar 1.008 portas de excesso. Uma denúncia contra 192.0.2.1, porta 2001, cai em 1024-5055: é o assinante 1, achado sem log do CGN, cruzando o endereço interno com os registros de lease do Dynamic Host Configuration Protocol () ou do Point-to-Point Protocol () (seção 2.3; veja o ciclo de vida do lease DHCP). A porta 58204 está no pool dinâmico, então o log de blocos aponta o assinante 2, "assuming that the public safety timestamp matches the operator timestamp", se os timestamps batem (seção 2.3). Mudanças nas variáveis precisam ser registradas (seção 3), e as portas são sorteadas dentro de cada faixa (seção 5).
NAT444 diante das alternativas
Todo desenho de IPv4-as-a-service traduz com estado em algum ponto: "The major differentiator is where in the architecture this function is located", onde fica a função (RFC 9313, seção 3.3). Na família baseada em CGN, o provedor guarda estado por sessão. Na família Address plus Port (A+P), que trata "some of the port number bits as part of an extended IPv4 address", bits da porta no endereço (RFC 6346, resumo), o CPE traduz a própria casa e a função central não guarda estado: Lightweight 4over6 (lw4o6) (RFC 7596, resumo), Mapping of Address and Port with Encapsulation (MAP-E) (RFC 7597, seção 1) e MAP using Translation (MAP-T) (RFC 7599, seção 1).
| Desenho | NAT com estado | IPv4 na rede de acesso | O que o provedor guarda para atribuição |
|---|---|---|---|
| NAT444 | CGN no provedor | IPv4 nativo | mappings ou port blocks |
| DS-Lite | no provedor, na ponta do túnel | em túnel sobre IPv6 | mappings ou port blocks |
| 464XLAT | no provedor | traduzido para IPv6 | mappings ou port blocks |
| lw4o6 | no CPE | em túnel sobre IPv6 | a binding table com timestamps |
| MAP-E | no CPE | em túnel sobre IPv6 | as regras MAP com timestamps |
| MAP-T | no CPE | traduzido para IPv6 | as regras MAP com timestamps |
O preço do A+P é que "the number of ports provided to each user (and hence the effective IPv4 address-sharing ratio) must be pre-provisioned to the client", portas fixadas de antemão (RFC 9313, seção 4.2); os desenhos com estado aproveitam melhor as portas, e logs por sessão podem exigir um tradutor central (seção 4.7). No MAP, um Port Set ID (PSID) de 6 bits depois do offset padrão de 6 bits dá 64 CPEs por endereço, cada um com 1.024 - 16 = 1.008 portas em sequências de 16 a cada 1.024 (RFC 7597, seção 5.1). Os túneis em si estão em IPv6 e IPv4 lado a lado.
A correção que acaba com o compartilhamento
"Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms", só o IPv6 resolve (RFC 6269, seção 1). Até o método que mais reduz o log recusa esse papel: "Deterministic CGN should in no way be understood as making CGN a replacement for IPv6 service", não substitui o IPv6 (RFC 7422, seção 4).
Como ver na prática
No roteador de casa, ou num host Linux que faça esse papel, liste os endereços dentro do shared space; to filtra por prefixo (ip-address(8)) e -4 seleciona IPv4 (ip(8)):
$ ip -4 address show to 100.64.0.0/10
Qualquer saída significa que o lado WAN está no shared space. Se ele difere do endereço que um servidor seu registra para a mesma conexão, algo traduz no meio; um endereço WAN em espaço RFC 1918 ou em espaço público não anunciado pode significar o mesmo (RFC 6598, seção 5.1). Um traceroute sem resolução de nomes (-n, traceroute(8)) mostra as duas camadas:
$ traceroute -n example.com
saída ilustrativa, tempos omitidos
1 192.168.1.1 o roteador de casa, espaço RFC 1918
2 100.64.0.1 o lado da operadora no link do CGN, shared space
3 203.0.113.1 hops públicos daqui em diante
O artigo ICMP, ping e traceroute explica as mensagens. Quem opera o CGN captura dos dois lados, com a primitiva net do pcap-filter(7) e o -n do tcpdump(1), e casa as capturas por protocolo, portas e horário: a origem vira um endereço do pool e uma porta, o destino não muda. O Packet Capture Plan Builder ajuda a escolher os dois pontos.
# tcpdump -n src net 100.64.0.0/10
Um servidor guarda a sua metade da tupla com um único ajuste: %a e %{remote}p no formato de log do Apache (Apache mod_log_config), smtpd_client_port_logging no Postfix (Postfix postconf(5)) e LogLevel VERBOSE no sshd (RFC 7768, apêndice A; sshd_config(5)), com os relógios no Network Time Protocol () e os logs em UTC.
# Apache httpd
LogFormat "%a %{remote}p %t" withport
CustomLog "logs/access_log" withport
# Postfix
smtpd_client_port_logging = yes
# OpenSSH sshd_config
LogLevel VERBOSE
No CGN, os registros têm três formatos: uma linha por mapping com os cinco campos da RFC 6888, uma linha por bloco como na RFC 7768 e o registro de configuração da RFC 7422: timestamp, prefixo e máscara internos, prefixo e máscara externos, D, M, A e portas reservadas (RFC 7422, seção 3).
ilustrativo, por mapping: 2026-10-19T14:02:11Z TCP 100.64.1.2:40000 -> 203.0.113.5:51234
ilustrativo, por bloco: 2026-10-19T14:02:11Z 100.64.1.2 -> 203.0.113.5 ports 2001-2300
RFC 7422, configuração: [Wed Oct 11 14:32:52 2000]:198.51.100.0:28:192.0.2.0:32:2:5040:0:1-1023,5004,5060.
O SSRF URL classifier, um verificador de server-side request forgery (), classifica http://100.72.0.1/ como espaço de carrier-grade NAT, com risco médio. A CIDR / Subnet Calculator, para blocos Classless Inter-Domain Routing (), mostra 100.64.0.0/10 como 4.194.304 endereços terminando em 100.127.255.255, mas não classifica a faixa. Nenhuma ferramenta calcula um port block ou um PSID do MAP; o Python playground roda a aritmética:
>>> (65536 - 1024) // 16
4032
>>> 1024 + 4032*1, 1024 + 4032*2 - 1
(5056, 9087)
>>> 33000 * 150 * 30 * 1_000_000 / 1e12
148.5
>>> 42.5e12 / 40.6e9
1046.7980295566501
>>> 2**(16 - 6) - 2**4
1008
Para lembrar
- Um CGN é um NAT da operadora que divide um endereço IPv4 público entre assinantes que não o controlam; somado ao NAT de casa, forma o NAT444, e 100.64.0.0/10 numera o link entre os dois.
- A RFC 6888 exige paired pooling, limite de portas por assinante e um protocolo de controle de mappings, recomenda endpoint-independent filtering e herda da RFC 4787 o endpoint-independent mapping.
- A RFC 7021 viu funcionar navegação, e-mail e remote desktop, e falhar o jogo entre duas casas, o seeding de BitTorrent, o SIP sem proxy, o servidor FTP em casa, o 6to4 e o Teredo.
- Um pedido respondível traz endereço de origem, source port e timestamp de relógios sincronizados; sem a porta, a resposta é todo mundo no endereço.
- Registrar cada conexão custa cerca de 4,95 MB por assinante por dia; port blocks dividem isso pelo tamanho do bloco, e o mapping determinístico troca a maior parte das consultas por aritmética.
- Desenhos baseados em CGN guardam estado por sessão no provedor; desenhos A+P provisionam conjuntos de portas de antemão e guardam só regras ou bindings com timestamps.
Fontes
- RFC 6888, Common Requirements for Carrier-Grade NATs (CGNs), abril de 2013: seções 1 a 5 e 7 (lida em 2026-10-19)
- RFC 6264, An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition, junho de 2011: seções 1, 2.1, 2.7 e 3 (lida em 2026-10-19)
- RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space, abril de 2012: seções 1, 3, 4, 5.2, 6 e 7 (lida em 2026-10-19)
- IANA, IPv4 Special-Purpose Address Registry (CSV): a linha de 100.64.0.0/10 (lida em 2026-10-19)
- NRO, Free Pool of IPv4 Address Space Depleted, 3 de fevereiro de 2011 (lida em 2026-10-19)
- APNIC, APNIC IPv4 Address Pool Reaches Final /8, 15 de abril de 2011 (lida em 2026-10-19)
- NRO, LACNIC Enters IPv4 Exhaustion Phase, 10 de junho de 2014 (lida em 2026-10-19)
- LACNIC, IPv4 Exhaustion: LACNIC Has Assigned the Last Remaining Address Block, 28 de agosto de 2020 (lida em 2026-10-19)
- ARIN, ARIN IPv4 Free Pool Reaches Zero, 24 de setembro de 2015 (lida em 2026-10-19)
- RIPE NCC, The RIPE NCC has run out of IPv4 Addresses, 25 de novembro de 2019 (lida em 2026-10-19)
- AFRINIC, IPv4 Exhaustion (lida em 2026-10-19)
- RFC 4787, Network Address Translation (NAT) Behavioral Requirements for Unicast UDP, janeiro de 2007: seções 4.1 e 5 (lida em 2026-10-19)
- RFC 6269, Issues with IP Address Sharing, junho de 2011: seções 1 a 3, 5, 6, 7, 12, 13, 18 e apêndices A e B (lida em 2026-10-19)
- RFC 7021, Assessing the Impact of Carrier-Grade NAT on Network Applications, setembro de 2013: seções 1, 2.2, 2.3, 2.5, 3, 4, 5.1 e 6 (lida em 2026-10-19)
- RFC 6302, Logging Recommendations for Internet-Facing Servers, junho de 2011: seções 1 a 4 (lida em 2026-10-19)
- Europol, Are you sharing the same IP address as a criminal? Law enforcement call for the end of Carrier Grade NAT (CGN) to increase accountability online, 17 de outubro de 2017 (lida em 2026-10-19)
- Europol, Internet Organised Crime Threat Assessment (IOCTA) 2017: páginas 62 a 64 (lidas em 2026-10-19)
- Lei nº 12.965, de 23 de abril de 2014 (Marco Civil da Internet), planalto.gov.br: artigos 5º, 10, 13 e 22 (lida em 2026-10-19)
- RFC 7422, Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments, dezembro de 2014: seções 1, 2, 2.3, 3, 4 e 5 (lida em 2026-10-19)
- RFC 7768, Port Management to Reduce Logging in Large-Scale NATs, janeiro de 2016: seções 1 a 3, 5 e apêndice A (lida em 2026-10-19)
- RFC 9313, Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS), outubro de 2022: seções 3.3, 3.4, 4.1.1, 4.2 e 4.7 (lida em 2026-10-19)
- RFC 6346, The Address plus Port (A+P) Approach to the IPv4 Address Shortage, agosto de 2011: resumo e seções 1, 1.1, 3.1 e 3.2 (lida em 2026-10-19)
- RFC 7596, Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture, julho de 2015: resumo e seção 1 (lida em 2026-10-19)
- RFC 7597, Mapping of Address and Port with Encapsulation (MAP-E), julho de 2015: seções 1, 5 e 5.1 (lida em 2026-10-19)
- RFC 7599, Mapping of Address and Port using Translation (MAP-T), julho de 2015: resumo e seção 1 (lida em 2026-10-19)
- ip-address(8), página de manual, man7.org (lida em 2026-10-19)
- ip(8), página de manual, man7.org (lida em 2026-10-19)
- traceroute(8), página de manual, man7.org (lida em 2026-10-19)
- pcap-filter(7), página de manual, man7.org (lida em 2026-10-19)
- tcpdump(1), página de manual, man7.org (lida em 2026-10-19)
- Apache HTTP Server 2.4 documentation, mod_log_config (lida em 2026-10-19)
- Postfix postconf(5), smtpd_client_port_logging (lida em 2026-10-19)
- sshd_config(5), página de manual, OpenBSD (lida em 2026-10-19)