Durante anos, a imprensa tem escrito sobre o problema de que agora há muito poucos endereços IPv4 disponíveis. Mas, por outro lado, estou usando uma empresa de hospedagem de servidores que de bom grado fornece endereços IPv4 públicos por uma pequena quantia de dinheiro. E minha conexão de internet privada vem com um endereço IPv4 público.
Como isso é possível? O problema é tão grave quanto a imprensa quer que acreditemos?
É muito ruim. Aqui está uma lista de exemplos do que tenho experiência em primeira mão com ISPs de consumidores fazendo para combater a escassez de endereços IPv4:
Tudo isso está reduzindo a qualidade do produto que o ISP está vendendo para seus clientes. A única explicação sensata de por que eles estariam fazendo isso com seus clientes é a falta de endereços IPv4.
A escassez de endereços IPv4 levou à fragmentação do espaço de endereços que apresenta várias deficiências:
Sem NAT não há como sobrevivermos hoje com os 3.700 milhões de endereços IPv4 roteáveis. Mas o NAT é uma solução frágil que oferece uma conectividade menos confiável e problemas difíceis de depurar. Quanto mais camadas de NAT pior será. Duas décadas de trabalho árduo fizeram com que uma única camada de NAT funcionasse, mas já ultrapassamos o ponto em que uma única camada de NAT era suficiente para contornar a escassez de endereços IPv4.
Antes de começarmos a ficar sem endereços IPv4, não usávamos (amplamente) NAT. Cada computador conectado à Internet teria seu próprio endereço globalmente exclusivo. Quando o NAT foi introduzido pela primeira vez, era para passar de fornecer aos clientes do ISP 1 endereço real por dispositivo que o cliente usava/possuir para fornecer 1 endereço real a 1 cliente. Isso resolveu o problema por um tempo (anos) enquanto deveríamos mudar para o IPv6. Em vez de mudar para o IPv6, (principalmente) todos esperavam que todos os outros mudassem e assim (principalmente) ninguém implementou o IPv6. Agora estamos enfrentando o mesmo problema novamente, mas desta vez, uma segunda camada de NAT está sendo implantada (CGN) para que os ISPs possam compartilhar 1 endereço real entre vários clientes.
A exaustão do endereço IP não é grande coisa se o NAT não for terrível, inclusive no caso em que o usuário final não tem controle sobre ele (Carrier Grade NAT ou CGN).
Mas eu diria que o NAT é terrível, especialmente no caso em que o usuário final não tem controle sobre ele. E (como uma pessoa cujo trabalho é engenharia/administração de rede, mas tem um diploma de engenharia de software) eu diria que, ao implantar o NAT em vez do IPv6, os administradores de rede transferiram o peso de resolver o esgotamento de endereços para fora de seu campo e para os usuários finais e desenvolvedores de aplicativos.
Então (na minha opinião), por que o NAT é uma coisa terrível e maligna que deve ser evitada?
Vamos ver se posso fazer justiça ao explicar o que ele quebra (e quais problemas ele causa que nos acostumamos tanto que nem percebemos que poderia ser melhor):
Vamos ver se consigo explicar cada um desses itens.
Independência da camada de rede
Os ISPs devem apenas passar os pacotes da camada 3 e não se importar com o que está nas camadas acima disso. Esteja você transmitindo TCP, UDP ou algo melhor/mais exótico (SCTP talvez? Cuidado; tudo deve parecer apenas dados para eles.
Mas isso não acontece - não quando eles estão implementando a "segunda onda" do NAT, o NAT "Carrier Grade". Então eles necessariamente precisam olhar e dar suporte aos protocolos da camada 4 que você deseja usar. No momento, isso praticamente significa que você só pode usar TCP e UDP. Outros protocolos seriam bloqueados / descartados (grande maioria dos casos na minha experiência) ou apenas encaminhados para o último host "dentro" do NAT que usou esse protocolo (vi uma implementação que faz isso). Mesmo o encaminhamento para o último host que usou esse protocolo não é uma correção real - assim que dois hosts o usam, ele é interrompido.
Imagino que existam alguns protocolos de substituição para TCP e UDP que não foram testados e não utilizados apenas por causa desse problema. Não me interpretem mal, TCP e UDP foram impressionantemente bem projetados e é incrível como ambos foram capazes de escalar para a maneira como usamos a Internet hoje. Mas quem sabe o que perdemos? Eu li sobre SCTP e parece bom, mas nunca usei porque era impraticável por causa do NAT.
Conexões ponto a ponto
Este é um grande problema. Na verdade, o maior na minha opinião. Se você tiver dois usuários finais, ambos por trás de seu próprio NAT, não importa qual tente se conectar primeiro, o NAT do outro usuário descartará o pacote e a conexão não será bem-sucedida.
Isso afeta jogos, bate-papo por voz/vídeo (como Skype), hospedagem de seus próprios servidores, etc.
Existem soluções alternativas. O problema é que essas soluções alternativas custam tempo do desenvolvedor, tempo e inconveniência do usuário final ou custos de infraestrutura de serviço. E eles não são infalíveis e às vezes quebram. (Veja os comentários de outros usuários sobre a interrupção sofrida pelo Skype.)
Uma solução alternativa é o encaminhamento de porta, onde você programa o dispositivo NAT para encaminhar uma porta de entrada específica para um computador específico atrás do dispositivo NAT. Existem sites inteiros dedicados a como fazer isso para todos os diferentes dispositivos NAT que existem por aí. Consulte https://portforward.com/ . Isso normalmente custa tempo e frustração do usuário final.
Outra solução alternativa é adicionar suporte para coisas como perfuração de aplicativos e manter a infraestrutura do servidor que não está por trás de um NAT para introduzir dois clientes NAT. Isso geralmente custa tempo de desenvolvimento e coloca os desenvolvedores em uma posição de potencialmente manter a infraestrutura do servidor onde ela não seria necessária anteriormente.
(Lembre-se do que eu disse sobre a implantação do NAT em vez do IPv6, mudando o peso do problema dos administradores de rede para usuários finais e desenvolvedores de aplicativos?)
Nomeação/localização consistente dos recursos de rede
Como um espaço de endereço diferente é usado no interior de um NAT e no exterior, qualquer serviço oferecido por um dispositivo dentro de um NAT tem vários endereços para alcançá-lo, e o correto a ser usado depende de onde o cliente está acessando. . (Isso ainda é um problema, mesmo depois que você fizer o encaminhamento de porta funcionar.)
Se você tem um servidor web dentro de um NAT, digamos na porta 192.168.0.23 porta 80, e seu dispositivo NAT (roteador/gateway) tem um endereço externo de 35.72.216.228, e você configura o encaminhamento de porta para a porta TCP 80, agora seu O servidor web pode ser acessado usando a porta 80 192.168.0.23 OU a porta 80 35.72.216.228. A que você deve usar depende se você está dentro ou fora do NAT. Se você estiver fora do NAT e usar o endereço 192.168.0.23, não chegará onde está esperando. Se você estiver dentro do NAT e usar o endereço externo 35.72.216.228, poderá chegar onde deseja, se sua implementação NAT for avançada que suporte hairpin, mas o servidor web que atende sua solicitação verá a solicitação como proveniente do seu dispositivo NAT. Isso significa que todo o tráfego deve passar pelo dispositivo NAT, mesmo que haja um caminho mais curto na rede por trás do NAT, e isso significa que os logs no servidor web se tornam muito menos úteis porque todos listam o dispositivo NAT como a origem do a conexão. Se sua implementação de NAT não suportar hairpin, você não chegará onde esperava.
E esse problema piora assim que você usa o DNS. De repente, se você quer que tudo funcione corretamente para algo hospedado atrás do NAT, você vai querer dar respostas diferentes no endereço do serviço hospedado dentro de um NAT, baseado em quem está perguntando (AKA split horizon DNS, IIRC). Que nojo.
E tudo isso supondo que você tenha alguém com conhecimento sobre encaminhamento de porta e NAT hairpin e DNS de horizonte dividido. E os usuários finais? Quais são suas chances de configurar tudo corretamente quando compram um roteador de consumidor e uma câmera de segurança IP e querem que ele "simplesmente funcione"?
E isso me leva a:
Roteamento ideal de tráfego, hosts sabendo seu endereço real
Como vimos, mesmo com o tráfego NAT hairpin avançado nem sempre flui pelo caminho ideal. Isso é mesmo no caso em que um administrador experiente configura um servidor e tem NAT hairpin. (O DNS de horizonte dividido concedido pode levar ao roteamento ideal do tráfego interno nas mãos de um administrador de rede.)
O que acontece quando um desenvolvedor de aplicativos cria um programa como o Dropbox e o distribui para usuários finais que não são especializados em configurar equipamentos de rede? Especificamente, o que acontece quando coloco um arquivo de 4 GB no meu arquivo de compartilhamento e tento acessá-lo no próximo computador? Ele é transferido diretamente entre as máquinas ou tenho que esperar que ele seja carregado em um servidor em nuvem por meio de uma conexão WAN lenta e, em seguida, aguardar uma segunda vez para que seja baixado pela mesma conexão WAN lenta?
Para uma implementação ingênua, ele seria carregado e depois baixado, usando a infraestrutura de servidor do Dropbox que não está atrás de um NAT como mediador. Mas se as duas máquinas pudessem perceber que estão na mesma rede, elas poderiam transferir o arquivo diretamente muito mais rápido. Portanto, para nossa primeira tentativa de implementação menos ingênua, podemos perguntar ao sistema operacional quais endereços IP(v4) a máquina possui e, em seguida, verificar isso com outras máquinas registradas na mesma conta do Dropbox. Se estiver na mesma faixa que nós, basta transferir diretamente o arquivo. Isso pode funcionar em muitos casos. Mas mesmo assim há um problema: o NAT só funciona porque podemos reutilizar endereços. E daí se o endereço 192.168.0.23 e o endereço 192.168.0. 42 endereços registrados na mesma conta do Dropbox estão em redes diferentes (como sua rede doméstica e sua rede de trabalho)? Agora você precisa fazer o failback para usar a infraestrutura do servidor do Dropbox para mediar. (No final, o Dropbox tentou resolver o problema fazendo com que cada cliente do Dropbox transmitisse na rede local na esperança de encontrar outros clientes. Mas essas transmissões não cruzam nenhum roteador que você possa ter por trás do NAT, o que significa que não é uma solução completa ,especialmente no caso de CGN .)
IPs estáticos
Além disso, desde a primeira escassez (e onda de NAT) aconteceu quando muitas conexões de consumidor não estavam sempre em conexões (como dial-up), os ISPs podiam fazer melhor uso de seus endereços alocando apenas endereços IP públicos/externos quando você estava realmente conectado. Isso significava que, quando você se conectava, recebia qualquer endereço disponível, em vez de sempre obter o mesmo. Isso torna a execução do seu próprio servidor muito mais difícil e torna o desenvolvimento de aplicativos ponto a ponto mais difícil porque eles precisam lidar com os pares se movendo em vez de estarem em endereços fixos.
Ofuscação da origem do tráfego malicioso
Como o NAT reescreve as conexões de saída como se fossem do próprio dispositivo NAT, todo o comportamento, bom ou ruim, é transferido para um endereço IP externo. Não vi nenhum dispositivo NAT que registre cada conexão de saída por padrão. Isso significa que, por padrão, a origem do tráfego malicioso passado só pode ser rastreada até o dispositivo NAT pelo qual passou. Embora os equipamentos mais corporativos ou de classe de operadora possam ser configurados para registrar cada conexão de saída, não vi nenhum roteador de consumidor que faça isso. Certamente acho que será interessante ver se (e por quanto tempo) os ISPs manterão um log de todas as conexões TCP e UDP feitas por meio de CGNs à medida que forem implantadas. Esses registros seriam necessários para lidar com reclamações de abuso e reclamações de DMCA.
Algumas pessoas pensam que o NAT aumenta a segurança. Se o fizer, fá-lo através da obscuridade. A queda padrão do tráfego de entrada que o NAT torna obrigatório é o mesmo que ter um firewall com estado. É meu entendimento que qualquer hardware capaz de fazer o rastreamento de conexão necessário para o NAT deve ser capaz de executar um firewall com estado, então o NAT realmente não merece nenhum ponto.
Protocolos que usam uma segunda conexão
Protocolos como FTP e SIP (VoIP) tendem a usar conexões separadas para controle e conteúdo de dados real. Cada protocolo que faz isso deve ter um software auxiliar chamado ALG (gateway de camada de aplicativo) em cada dispositivo NAT pelo qual passa, ou contornar o problema com algum tipo de mediador ou perfuração. Na minha experiência, os ALGs raramente são atualizados e têm sido a causa de pelo menos alguns problemas com os quais lidei envolvendo o SIP. Sempre que ouço alguém relatar que o VoIP não funcionou para eles porque o áudio só funcionava de uma maneira, instantaneamente suspeito que em algum lugar há um gateway NAT descartando pacotes UDP com os quais não consegue descobrir o que fazer.
Em resumo, o NAT tende a quebrar:
No núcleo, a abordagem em camadas que a pilha de rede adota é relativamente simples e elegante. Tente explicá-lo a alguém novo em redes, e eles inevitavelmente assumem que sua rede doméstica é provavelmente uma rede boa e simples de tentar entender. Eu vi isso levar em alguns casos a algumas idéias bastante interessantes (excessivamente complicadas) sobre como o roteamento funciona devido à confusão entre endereços externos e internos.
Suspeito que sem NAT, o VoIP seria onipresente e integrado ao PSTN, e que fazer chamadas de um celular ou computador seria gratuito (exceto pela internet pela qual você já pagou). Afinal, por que eu pagaria pelo telefone quando você e eu podemos abrir um fluxo VoIP de 64K e funciona tão bem quanto o PSTN? Parece que hoje, o problema número 1 com a implantação de VoIP está passando por dispositivos NAT.
Suspeito que geralmente não percebemos o quanto muitas coisas poderiam ser mais simples se tivéssemos a conectividade de ponta a ponta que o NAT quebrou. As pessoas ainda enviam arquivos por e-mail (ou Dropbox) porque o problema principal é precisar de um mediador para quando dois clientes estão por trás do NAT.
Um grande sintoma da exaustão do IPv4 que não vi mencionado em outras respostas é que alguns provedores de serviços móveis começaram a usar apenas o IPv6 há vários anos. Há uma chance de você estar usando IPv6 há anos e nem saber disso. Os provedores móveis são mais novos no jogo da Internet e não têm necessariamente grandes alocações de IPv4 pré-existentes para usar. Eles também exigem mais endereços do que cabo/DSL/fibra, porque seu telefone não pode compartilhar um endereço IP público com outros membros da sua casa.
Meu palpite é que os provedores de IaaS e PaaS serão os próximos, devido ao seu crescimento que não está vinculado aos endereços físicos dos clientes. Eu não ficaria surpreso em ver provedores de IaaS oferecendo apenas IPv6 com desconto em breve.
Os principais RIRs ficaram sem espaço para alocações normais há algum tempo. Para a maioria dos provedores, portanto, as únicas fontes de endereços IPv4 são seus próprios estoques e os mercados.
Existem cenários em que é preferível ter um IP IPv4 público dedicado, mas não é absolutamente essencial. Há também vários endereços IPv4 públicos que são alocados, mas não estão em uso na Internet pública (eles podem estar em uso em redes privadas ou podem não estar em uso). Finalmente, existem redes mais antigas com endereços alocados de forma muito mais flexível do que o necessário.
Os três maiores RIRs agora permitem que os endereços sejam vendidos tanto entre seus membros quanto entre os membros. Portanto, temos um mercado entre organizações que têm endereços que não estão usando ou que têm endereços que podem ser liberados por um custo de um lado e organizações que realmente precisam de mais endereços IP do outro.
O que é difícil de prever é quanta oferta e demanda haverá em cada ponto de preço e, portanto, o que o preço de mercado fará no futuro. Até agora, o preço por IP parece ter permanecido surpreendentemente baixo.
Idealmente, cada host na Internet deve ser capaz de obter um endereço IP de escopo global, no entanto, o esgotamento do endereço IPv4 é real, de fato, o ARIN já ficou sem endereço em seu pool gratuito .
A razão pela qual todos ainda podem acessar os serviços de Internet muito bem, é graças às técnicas de tradução de endereços de rede (NAT) que permitem que vários hosts compartilhem endereços IP públicos. No entanto, isso não vem sem problemas.
Você já obteve muitas respostas excelentes, mas gostaria de acrescentar algo que ainda não foi mencionado.
Sim, o esgotamento do endereço IPv4 é ruim, dependendo de como você o mede. Algumas empresas ainda têm uma enorme oferta de endereços IPv4, mas estamos começando a ver soluções alternativas como NAT de nível de operadora.
Mas muitas das respostas estão erradas quando se desviam para o IPv6.
Aqui está uma lista de tecnologias que podem ajudar a lidar com a escassez de endereços IPv4. Cada um tem suas próprias vantagens e desvantagens.
IPv6
Outra consideração: mesmo que o IPv6 pegasse completamente hoje, ainda levaria mais 20 anos ou mais para eliminar o IPv4, devido a equipamentos legados que as pessoas usarão por muito tempo (ainda vejo servidores Windows 2003 e estações de trabalho Windows XP ocasionalmente! Sem mencionar todas as impressoras e câmeras e gadgets de IoT que não suportam IPv6).
Eventualmente, CGNat não será suficiente. Talvez o IPv6 pegue, mas também é bem possível que acabemos vendo NAT de nível nacional, ou algo nesse sentido.
Atualmente, como consultor, muitas vezes tenho que apontar para meus clientes que eles estão expostos no IPv6 (muitas vezes graças ao Teredo). A próxima pergunta será invariavelmente: "quanto custa consertar isso?" e então "Quanto custa bloqueá-lo? O que perdemos se o desligarmos?" Adivinhe qual será a decisão de cada vez.
Resumindo: para responder à sua pergunta, sim, o esgotamento do IPv4 é real. E veremos alguns mecanismos para lidar com isso. O IPv6 pode ou não acabar sendo a equação.
Para ser claro: não estou dizendo que gosto dessa situação. Eu gostaria que o IPv6 tivesse sucesso (e gostaria de ver uma série de melhorias no IPv6). Estou apenas olhando para a situação como ela está no terreno agora.
Os ISPs costumavam distribuir blocos de 256 endereços IP para empresas. Agora, os ISPs são mesquinhos e dão a você (uma empresa) como 5. Antigamente (2003), todo PC e dispositivo conectado em sua casa tinha seu próprio endereço IP de internet. Agora, o roteador a cabo/DSN/Fios tem um endereço IP e fornece endereços ip 10.0.0.x para todos os PCs em sua casa. Resumo: Os ISPs costumavam desperdiçar endereços IP e agora não os desperdiçam mais.
NAT é o que aconteceu quando o IPv6 era uma ideia, antes de ser realidade, e a alocação de endereços IP estava se tornando um problema real (alguém se lembra quando eles estavam distribuindo Classe C basicamente para pedir?) e o mundo real precisava de uma solução nesse meio tempo .
NAT não é suficiente para IoT. Se a IoT vai acontecer, vai acontecer com o IPv6. A natureza da IoT está mais alinhada com a forma como o mundo dial-up funcionava, exceto que haverá várias ordens de magnitude a mais de dispositivos conectados ao mesmo tempo.
Toda a questão do endereço IPv4 é bastante complicada. Você pode encontrar certo artigo informando que está esgotado, outro falando sobre um grande número de endereços excedentes (nunca usados) sendo vendidos de uma parte para outra. A questão seria por que eles não estão disponíveis para aqueles (regiões emergentes e áreas rurais de países desenvolvidos) com falta deles?
Abaixo está o resultado de um estudo em que nos aventuramos acidentalmente. Ele utiliza nada mais do que o protocolo IPv4 original RFC791 e o bloco de endereços 240/4, há muito reservado, mas pouco utilizado, para expandir o pool IPv4 em 256 milhões de vezes. Apresentamos uma proposta preliminar chamada EzIP (fonética para Easy IPv4) ao IETF:
https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space-03
Basicamente, a abordagem EzIP não apenas resolverá problemas de escassez de endereços IPv4, mas também mitigará amplamente a causa raiz das vulnerabilidades de segurança cibernética, além de abrir novas possibilidades para a Internet, tudo dentro dos limites do domínio IPv4. Na verdade, esse esquema pode ser implantado "furtivamente" para regiões isoladas quando necessário. Isso deve aliviar a urgência de implantar o IPv6 por um período de tempo apreciável e invalidar o mercado de negociação de endereços IPv4.
Qualquer pensamento ou comentário será muito apreciado.
Abe(2018-07-15 17:29)
Honestamente, eu acho que não é tão ruim quanto as pessoas pensam. Sim, talvez em alguns lugares, mas não tanto porque não há endereços suficientes. É porque eles são todos de propriedade. Talvez seja a minha localização ou algo assim, mas eu fiz trabalho de TI para um monte de pequenas e médias empresas nos últimos sete anos, e todas as coisas de que vocês estão falando geralmente são apenas configuração padrão. Muito fácil, a menos que você tenha um dispositivo ruim, ou haja uma configuração de merda com a rede em primeiro lugar que precisa ser resolvida.
Pessoalmente, estou bem com o NAT. É uma camada adicional de proteção, em geral. Pelo menos eles precisam passar por um dispositivo extra ou encontrar uma maneira de seqüestrar indiretamente minha conexão. No que diz respeito à execução de servidores, isso geralmente está fora e/ou considerado uma violação de contrato com seu ISP, a menos que você pague por isso. Claro que você pode fazer isso, e eles provavelmente não vão incomodá-lo sobre isso, mas eles podem.
Port-forwarding e tudo o que não é exatamente complicado. Agora, talvez alguns dispositivos não sejam fáceis de configurar, mas não é por causa do IPv4. Ele ainda oferece a maior compatibilidade simplesmente porque é onipresente.
Na verdade, ninguém precisa enviar um e-mail para si mesmo, e enviar algo para o Drop-box ou Google Drive, ou um milhão de outros serviços semelhantes, não é exatamente ciência do foguete, nem lento, nos dias de hoje. Quero dizer, tudo sincroniza. Você o solta em uma pasta. A menos que você seja nerd como eu e faça tudo através de ssh/sftp (ok, não tudo ). E se você tiver algum motivo para realmente querer rodar seu próprio servidor, a hospedagem na nuvem é barata -- eu tenho um servidor virtual dedicado que roda linux em um ssd. A largura de banda é loucamente rápida. Ele inicializa mais rápido do que eu posso digitar uma seta para cima e pressionar Enter. E é escalável Todo o setup custa entre 5 e 10 dólares por mês, com backups grátis e sem conta de luz.
Não precisa realmente de uma solução de rede de pares. Até mesmo a maioria dos jogos multiusuário hoje em dia são todos configurados para interagir através de um servidor interveniente, todos configurados e pré-configurados. Por outro lado, se o que estou lendo neste post for verdade, a TI estará superlotada e barata se/quando o IPv6 decolar. Até os celulares estão se aproximando de velocidades semelhantes às da fibra. Ou pelo menos cabo.
Se você executar um servidor interno e precisar acessá-lo com o mesmo nome de domínio dentro ou fora de sua rede, sempre poderá falsificar seu endereço usando um roteador baseado em linux e dnsmasq ou qualquer outra coisa e entradas personalizadas nos hosts arquivo para redirecioná-lo para o endereço local, se você estiver por dentro.
Realmente, eu não acho que seja realmente desejável que cada dispositivo tenha seu próprio endereço flutuando aberto na rede. Se alguém quiser se ofuscar enquanto ataca você, isso acontecerá de qualquer maneira. Mas você é um pato sentado se você está apenas sentado lá fora na brisa aberta. Nah, eu vou pegar meu IPv4 e meu NAT qualquer dia. Mas é bom que esteja lá.
De qualquer forma, adormecendo agora... provavelmente mais a dizer, mas eu vou checar amanhã caso eu tenha perdido alguma coisa. Tenho certeza que há mais.