Quão ruim é a exaustão do endereço IPv4?


163

Há anos a imprensa escreve sobre o problema de que agora existem muito poucos endereços IPv4 disponíveis. Mas, por outro lado, estou usando uma empresa de hospedagem de servidores que oferece endereços IPv4 públicos por uma pequena quantia de dinheiro. E minha conexão privada à Internet vem com um endereço IPv4 público.

Como isso é possível? O problema é tão ruim quanto a imprensa quer que acreditemos?


23
Algumas empresas ainda têm muitos endereços IPv4 em mãos. Outros têm muito pouco. Eu tenho que pensar com muito cuidado em usar um endereço IPv4; Como resultado, tenho várias máquinas apenas para IPv6.
Michael Hampton

21
Também fornece uma perspectiva da quantidade de dor que os ISPs estão dispostos a causar a outras pessoas, apenas para evitar a implantação do IPv6.
immibis 28/01

22
Eu não chamaria isso de mau , mas certamente é uma dor. Dito isto, a maioria dos consumidores provavelmente não se importaria com a natureza, assumindo que o facebook e o whatsapp funcionem ._.
Journeyman Geek

8
@JourneymanGeek Bem, os consumidores médios não se importam com nada que não entendam. Existem idéias para mídias sociais distribuídas, por exemplo (porque isso dificulta a censura), mas ninguém se preocupa com essas coisas até depois de decolarem, o que não pode por causa do NAT. Ouso dizer que o NAT é uma das razões pelas quais acabamos com uma Web centralizada, porque é basicamente impossível hospedar seu próprio site sem pagar alguém.
immibis

15
Como apontou @Azendale, a hospedagem de servidores de jogos é grande. Por que não consigo simplesmente executar o minecraft_server.exe e fornecer meu endereço a meus amigos? Por causa do NAT. Os "consumidores" certamente querem rodar servidores de jogos às vezes.
immibis

Respostas:


176

É muito ruim. Aqui está uma lista de exemplos do que tenho experiência em primeira mão com ISPs de consumidores para combater a falta de endereços IPv4:

  • Trocar repetidamente os blocos IPv4 entre cidades, causando breves interrupções e redefinições de conexão para os clientes.
  • Diminuindo o tempo de concessão do DHCP de dias para minutos.
  • Permita que os usuários escolham se desejam conversão de endereço de rede (NAT) no Customer Premise Equipment (CPE) ou não e, em seguida, ative-o de forma retroativa para todos.
  • Ativando o NAT no CPE para clientes que já usaram a oportunidade de optar por não participar do NAT.
  • Reduzir o limite para o número de endereços de controle de acesso à mídia (MAC) ativos simultaneamente aplicados pelo CPE.
  • Implantando NAT de classe de operadora (CGN) para clientes que tinham um endereço IP real quando se inscreveram no serviço.

Tudo isso reduz a qualidade do produto que o ISP está vendendo para seus clientes. A única explicação sensata para o motivo de eles estarem fazendo isso com seus clientes é a falta de endereços IPv4.

A falta de endereços IPv4 levou à fragmentação do espaço de endereço que possui várias falhas:

Sem o NAT, não há como sobreviver hoje com os 3700 milhões de endereços IPv4 roteáveis. Mas o NAT é uma solução quebradiça 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 duro fizeram com que uma única camada de NAT funcionasse principalmente, mas já cruzamos o ponto em que uma única camada de NAT era suficiente para solucionar a escassez de endereços IPv4.


57
Uma coisa a acrescentar é que o NAT também leva usuários mal-intencionados a impactar usuários normais e geralmente torna o IP não confiável como um mecanismo de diferenciação de usuário. Por exemplo, a Wikipedia bloqueia quase todos os usuários do Catar devido ao vandalismo de um ou alguns usuários.
usar o seguinte código

9
@IllusiveBrian faz uma observação válida. Eu herdei o software de segmentação de anúncios que usava endereços IP como identificador principal. Isso não é nem de longe suficiente nos dias de hoje e teve que ser extensivamente modificado para mantê-lo confiável. Índia e Grécia parecem ser dois dos países mais afetados. Eu posso ver um anúncio ser atingido 100+ vezes por dia a partir do mesmo IPv4, mas cada hit pode ser um usuário diferente, determinado por outros métodos de rastreamento
Darren H

15
@DmitriySintsov não seria mais do que um simples firewall com estado. Se um dispositivo de borda pode executar NAT, ele pode fazer firewall com estado.
mfinni

15
@DarrenH "software de segmentação de anúncios que usava endereços IP como identificador primário ... e teve que ser extensivamente modificado para mantê-lo confiável." Bem, esse motivo é suficiente para manter o NAT.
Andy

6
@ DarrenH É apenas um comentário sobre não gostar de software de anúncios, seja qual for o tom que você esteja sentindo em sua própria cabeça.
Andy

132

Antes de começarmos a ficar sem endereços IPv4, não usamos (amplamente) o NAT. Todo computador conectado à Internet teria seu próprio endereço globalmente exclusivo. Quando o NAT foi introduzido pela primeira vez, passou de fornecer aos clientes do ISP 1 endereço real por dispositivo que o cliente usava / possuía para fornecer 1 endereço real a 1 cliente. Isso resolveu o problema por um tempo (anos) enquanto devíamos mudar para o IPv6. Em vez de mudar para o IPv6, (principalmente) todos esperavam que todos mudassem e, portanto, (principalmente) ninguém lançava 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 um 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 (NAT ou CGN de ​​grau de operadora).

Mas eu argumentaria 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 possui um diploma em engenharia de software), eu argumentaria que, ao implantar o NAT em vez do IPv6, os administradores de rede mudaram o peso de resolver a exaustão de endereços 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 eu posso fazer justiça ao explicar o que quebra (e quais os problemas causados ​​por nós nos acostumamos tanto que nem percebemos que poderia ser melhor):

  • Independência da camada de rede
  • Conexões ponto a ponto
  • Nomeação e localização consistentes de recursos
  • Roteamento ideal de tráfego, hosts sabendo seu endereço real
  • Rastreando a origem do tráfego malicioso
  • Protocolos de rede que separam dados e controlam em conexões separadas

Vamos ver se consigo explicar cada um desses itens.

Independência da camada de rede

Os ISPs devem apenas passar pacotes da camada 3 e não se importar com o que está nas camadas acima disso. Esteja você passando TCP, UDP ou algo melhor / mais exótico (talvez SCTP? Ou mesmo algum outro protocolo que seja melhor que TCP / UDP, mas que seja obscuro por falta de suporte a NAT), seu ISP não deve Cuidado; tudo deve parecer com dados para eles.

Mas isso não acontece - não quando eles estão implementando a "segunda onda" do NAT, NAT "Carrier Grade". Então eles necessariamente precisam examinar 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 apenas bloqueados / descartados (grande parte dos casos na minha experiência) ou apenas encaminhados para o último host "dentro" do NAT que usava esse protocolo (eu já vi 1 implementação que faz isso). Mesmo encaminhar para o último host que usou esse protocolo não é uma correção real - assim que dois hosts o usam, ele quebra.

Eu imagino que existem alguns protocolos de substituição para TCP e UDP por aí que atualmente não são testados e não são usados ​​apenas por causa desse problema. Não me interpretem mal, o TCP e o UDP foram impressionantemente bem projetados e é incrível como os dois foram capazes de escalar a maneira como usamos a Internet hoje. Mas quem sabe o que perdemos? Eu li sobre o SCTP e parece bom, mas nunca o 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 atrás do seu próprio NAT, não importa qual deles 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 o Skype), hospedando seus próprios servidores, etc.

Existem soluções alternativas. O problema é que essas soluções alternativas custam tempo do desenvolvedor, tempo do usuário final e inconveniência 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, em que 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 existentes no mercado. Consulte https://portforward.com/ . Isso normalmente custa tempo e frustração ao usuário final.

Outra solução alternativa é adicionar suporte a coisas como perfuração nos aplicativos e manter a infraestrutura do servidor que não está atrás de um NAT para apresentar dois clientes com NAT. Isso geralmente custa tempo de desenvolvimento e coloca os desenvolvedores em uma posição de manutenção potencial da 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 de o IPv6 mudar o peso do problema dos administradores de rede para usuários finais e desenvolvedores de aplicativos?)

Nomeação / localização consistente de recursos de rede

Como um espaço de endereço diferente é usado na parte interna 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 o encaminhamento de porta está funcionando.)

Se você possui um servidor Web dentro de um NAT, digamos na porta 192.168.0.23, porta 80, e seu dispositivo NAT (roteador / gateway) possui um endereço externo 35.72.216.228, e você configura o encaminhamento de porta para a porta TCP 80, agora seu o servidor da web pode ser acessado usando a porta 80 ou 192.168.0.23 da porta 80 ou 35.72.216.228 porta 80. O 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á ao ponto esperado. Se você estiver dentro do NAT e usar o endereço externo 35.72.216.228, poderá chegar onde deseja, se a implementação do NAT for avançada e suportar hairpin, mas o servidor da 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 se houver um caminho mais curto na rede atrás do NAT, e significa que os logs no servidor da Web se tornam muito menos úteis, porque todos listam o dispositivo NAT como a fonte de a conexão. Se sua implementação de NAT não suportar hairpin, você não chegará aonde esperava.

E esse problema piora assim que você usa o DNS. De repente, se você deseja que tudo funcione corretamente para algo hospedado por trás do NAT, você deve dar respostas diferentes sobre o endereço do serviço hospedado dentro de um NAT, com base em quem está perguntando (AKA split horizon DNS, IIRC). Que nojo.

E isso pressupõe 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 as chances de que tudo esteja configurado corretamente quando eles compram um roteador de consumidor e uma câmera de segurança IP e querem que "funcione"?

E isso me leva a:

Roteamento ideal de tráfego, hosts sabendo seu endereço real

Como vimos, mesmo com o hairpin avançado, o tráfego NAT nem sempre flui através do caminho ideal. Isso ocorre mesmo no caso em que um administrador experiente configura um servidor e possui um NAT hairpin. (O DNS com divisão de horizonte 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 se especializam em configurar equipamentos de rede? Especificamente, o que acontece quando coloco um arquivo de 4 GB no meu arquivo de compartilhamento e tento acessar o próximo computador novamente? Ele é transferido diretamente entre as máquinas ou eu tenho que esperar o upload para um servidor em nuvem por meio de uma conexão WAN lenta e, em seguida, esperar uma segunda vez para fazer o download pela mesma conexão lenta WAN?

Para uma implementação ingênua, ela seria carregada e baixada, 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 rapidamente. Portanto, em nossa primeira tentativa de implementação menos ingênua, poderíamos perguntar ao sistema operacional qual o endereço IP (v4) da máquina e verificar isso com outras máquinas registradas na mesma conta do Dropbox. Se estiver no mesmo intervalo que nós, basta transferir diretamente o arquivo. Isso pode funcionar em muitos casos. Mas mesmo assim há um problema: o NAT funciona apenas porque podemos reutilizar endereços. E daí se o endereço 192.168.0.23 e 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 comercial)? Agora você deve voltar a usar a infraestrutura do servidor 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 da CGN .)

IPs estáticos

Além disso, como a primeira escassez (e onda de NAT) ocorreu quando muitas conexões de consumidores nem sempre estavam em conexões (como discagem), os ISPs poderiam usar melhor seus endereços alocando apenas endereços IP públicos / externos quando você estava realmente conectado. Isso significava que, quando você se conectava, obtinha 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 o desenvolvimento de aplicativos ponto a ponto, porque eles precisam lidar com os colegas que se deslocam ao invés de estarem em endereços fixos.

Ofuscação da fonte de tráfego malicioso

Como o NAT reescreve as conexões de saída como se fossem provenientes do próprio dispositivo NAT, todo o comportamento, bom ou ruim, é rolado em um endereço IP externo. Não vi nenhum dispositivo NAT que registrasse 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 no dispositivo NAT pelo qual passou. Embora o equipamento da classe da empresa ou da operadora possa ser configurado para registrar cada conexão de saída, eu não vi nenhum roteador de consumidor que faça isso. Eu 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 lançadas. Esses registros seriam necessários para lidar com reclamações de abuso e DMCA.

Algumas pessoas pensam que o NAT aumenta a segurança. Se isso acontecer, o faz 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. Entendo que qualquer hardware capaz de fazer o rastreamento de conexão necessário para o NAT possa executar um firewall com estado, para que o NAT realmente não mereça 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 da camada de aplicativo) em cada dispositivo NAT por onde passa ou solucionar o problema com algum tipo de mediador ou perfuração. Na minha experiência, os ALGs raramente são atualizados, e foram a causa de pelo menos alguns problemas com os quais eu lidei envolvendo o SIP. Sempre que ouço alguém relatar que o VoIP não funcionou para eles, porque o áudio só funcionou de uma maneira, suspeito instantaneamente que em algum lugar existe um gateway NAT que libera pacotes UDP e não consegue descobrir o que fazer.

Em resumo, o NAT tende a quebrar:

  • protocolos alternativos ao TCP ou UDP
  • sistemas ponto a ponto
  • acessando algo hospedado atrás do NAT
  • coisas como SIP e FTP. Os ALGs para contornar isso ainda causam problemas aleatórios e estranhos atualmente, especialmente com o SIP.

No núcleo, a abordagem em camadas adotada pela pilha de rede é relativamente simples e elegante. Tente explicá-lo a alguém novo na rede, e eles inevitavelmente assumem que sua rede doméstica é provavelmente uma rede boa e simples de tentar entender. Eu já 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.

Eu suspeito que, sem o NAT, o VoIP seria onipresente e integrado à PSTN, e que fazer chamadas de um telefone 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 simplesmente abrir um fluxo de 64K VoIP e funciona tão bem quanto a PSTN? Hoje parece que o problema número 1 na implantação do VoIP está passando pelos dispositivos NAT.

Suspeito que geralmente não percebemos o quanto as coisas poderiam ser mais simples se tivéssemos a conectividade de ponta a ponta que o NAT quebrou. As pessoas ainda enviam por e-mail (ou Dropbox) os próprios arquivos porque se o problema principal é precisar de um mediador para quando dois clientes estão atrás do NAT.


3
Os endereços IPv6 do @supercat são globalmente exclusivos, mas não são planos (para oferecer suporte ao roteamento, que precisa ser hierárquico). Parece-me que, se queremos que dois hosts conectados à Internet possam, teoricamente, se comunicar, são necessários endereços globalmente exclusivos de alguma forma.
Jakob

9
Infelizmente, é um mito persistente que o IPv6 ainda não tenha espaço suficiente para todos. Você pode dar um / 48 a todos na terra e ainda ter grandes quantidades de espaço sobrando. Para esgotar o alocado atualmente, 2000::/3você teria que repetir esse exercício mais de 4.000 vezes! ou dê a todos um / 34. Mas um / 48 é bom o suficiente para praticamente todo mundo, e quem precisa de mais pode obtê-lo facilmente. Mesmo se isso não bastasse, ainda há 4000::/3, 6000::/3, etc., disponíveis. Temos muito espaço; é hora de usá-lo. Veja também RFC 6177 .
Michael Hampton

7
@immibis Parece que você perdeu alguma coisa. As organizações não se limitam a obter um / 48 ou um / 32. Eles podem obter praticamente qualquer tamanho de bloco. Pode ser um / 44 ou a / 40 ou / 39 ou / 47 ou o que for. Você também deve ler a RFC 6177.
Michael Hampton

4
Infelizmente, muitas pessoas começaram a usar o NAT como uma forma de baixa qualidade de segurança e muitos dispositivos, como chromecasts e dispositivos IoT, assumem que qualquer dispositivo capaz de se conectar a ele é um dispositivo confiável, de modo que todos os roteadores de consumidor que eu vi baixam as conexões de entrada para dispositivos ipv6 e alguns que eu vi não têm como desativar isso, apenas o encaminhamento de porta regular.
Qwertie

14
... Ok, eu odeio o NAT agora; como eu mudo para o IPv6?
Adam Barnes

20

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 o IPv6 - há apenas alguns anos. Há uma chance de você estar usando o IPv6 há anos e nem sabia disso. Os provedores móveis são mais novos no jogo da Internet e não têm necessariamente grandes alocações IPv4 preexistentes. Eles também exigem mais endereços que cabo / DSL / fibra, porque seu telefone não pode compartilhar um endereço IP público com outros membros da sua família.

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. Não ficaria surpreso ao ver provedores de IaaS oferecendo apenas IPv6 com desconto em breve.


10
Eu já vi alguns pequenos fornecedores oferecendo VMs somente IPv6 e cobrando um prêmio pelo IPv4.
Michael Hampton

14

Os RIRs principais ficaram sem espaço para alocações normais há um tempo atrás. 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 público IPv4 dedicado, mas isso não é absolutamente essencial. Também existem vários endereços IPv4 públicos alocados, mas não atualmente 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 muito mais livremente do que precisam.

Os três maiores RIRs agora permitem a venda de endereços entre seus membros e entre si. Portanto, temos um mercado entre organizações que possuem endereços que não estão usando ou que têm endereços que podem ser liberados por um custo por um lado e organizações que realmente precisam de mais endereços IP por outro.

O que é difícil prever é quanta oferta e demanda haverá a cada 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.


O AfriNIC ainda tem menos de um valor de 8 endereços disponíveis, e já vi muitos exemplos de organizações fora da África pegando esses endereços.
Michael Hampton

7

Idealmente, todos os hosts da Internet devem obter um endereço IP de escopo global; no entanto, a exaustão do endereço IPv4 é real, na verdade o ARIN já ficou sem endereço em seu pool gratuito .

A razão pela qual todos ainda podem acessar bem os serviços da Internet é graças às técnicas de conversão de endereços de rede (NAT) que permitem que vários hosts compartilhem endereços IP públicos. No entanto, isso não ocorre sem problemas.


18
Não quero saber quantas horas de trabalho, recursos e milhões foram desperdiçados entre Napster, Gnutella, Gossip, Kazaa, BitTorrent, Kademlia, FastTrack, eDonkey, Freenet, Grokster, Skype, Threema, Spotify e assim por diante. , desenvolvendo técnicas de perfuração de NAT.
Jörg W Mittag

@ JörgWMittag Sem mencionar o quão espetacular ele falhou para Skype em dezembro de 2010.
kasperd

4
E o fato de que você precisa usar técnicas de perfuração de NAT em primeiro lugar. Se as máquinas X e Y estiverem em conexões comuns, elas não poderão se comunicar sem um mediador. Irritante para coisas como tarefas de sincronização de arquivos.
Loren Pechtel

@kasperd Você poderia falar sobre isso "falhou no Skype em dezembro de 2010"? Pude descobrir que um grande número de supernós falhou ao mesmo tempo, por algum motivo não especificado . E não veja como isso é relevante para a exaustão do endereço IPv4.
Ivan_pozdeev 02/02/19

5
@ivan_pozdeev Supernodes é uma solução alternativa para problemas causados ​​pelo NAT. O próprio NAT é uma solução alternativa para a falta de endereços IPv4. Portanto, a necessidade do Skype usar supernós foi motivada inteiramente pela falta de endereços IPv4. Se a Internet tivesse sido atualizada para o IPv6 em um ritmo mais razoável, o Skype não precisaria de supernós e essa interrupção específica não teria acontecido.
kasperd

5

Os ISPs costumavam distribuir blocos de 256 endereços IP às empresas. Agora, os provedores de serviços de Internet são mesquinhos e oferecem a você (uma empresa) como 5. Na época (2003), todos os PCs e dispositivos conectados em sua casa tinham seu próprio endereço IP de Internet. Agora, o roteador a cabo / DSN / Fios possui um endereço IP e fornece endereços IP 10.0.0.x a todos os PCs em sua casa. Resumo: os ISPs costumavam desperdiçar endereços IP e agora não os desperdiçam mais.


5
" Naquela época (2003), todos os PCs e dispositivos conectados em sua casa tinham seu próprio endereço IP de internet. " Somente se você pagou pelo 2º, 3º, 4º etc. etc.
RonJohn

2
RonJohn está correto. Eu fui um dos primeiros a adotar a banda larga quando a internet a cabo chegou à minha região em 1997. Paguei US $ 50 (EUA) por mês por isso, e lembro-me claramente de que eles ofereceram um segundo endereço IP por US $ 20 adicionais por mês. Mesmo que eu quisesse um, não estava disposto a pagar por isso. No ano seguinte, meu problema foi resolvido quando descobri dispositivos NAT. Eles não tinham muitos recursos (como encaminhamento de porta para conexões de entrada), mas o que obtive resolveu minha necessidade imediata.
Charles Burge

@CharlesBurge Também me lembro disso. E estamos vendo alguns fornecedores tentarem fazer a mesma coisa com o IPv6 agora também.
Kevin Keane

@CharlesBurge: Isso dependia do seu ISP. Eu tinha um amigo por cabo em Phoenix, AZ na mesma época, e ele conseguiu uma sub-rede totalmente roteada, um bloco / 29, com 8 endereços, 5 utilizáveis. Executamos um servidor Linux nele com gated (por acidente da nossa parte), e a rede a cabo realmente compartilhou informações completas de roteamento BGP com ele. Isso e as pessoas que colocaram seus PCs e impressoras Windows com compartilhamentos totalmente abertos na rede tornaram a vida interessante.
Zan Lynx

Ah sim, eu me lembro da visibilidade da rede. Todos os outros membros do meu loop estavam visíveis em "Ambiente de rede" e eu pude navegar em todos os compartilhamentos que eles tinham.
Charles Burge

5

Você já tem muitas respostas excelentes, mas eu gostaria de acrescentar algo que ainda não foi mencionado.

Sim, a exaustão do endereço IPv4 é ruim, dependendo de como você a 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 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 falta de endereços IPv4. Cada um tem suas próprias vantagens e desvantagens.

  • IPv6

    • Vantagem: padronizada e disponível na maioria dos sistemas operacionais.
    • Desvantagem: apesar das frequentes declarações em contrário, sérios problemas de segurança. Já em 2005, o US CERT alertou para problemas de segurança causados ​​pelo endereçamento global do IPv6. O IPv6 pode ser protegido adequadamente, mas, devido ao estado dos roteadores de consumidor, isso pode não acontecer.
    • Desvantagem: a migração leva tempo, dinheiro e conhecimento.
    • Desvantagem: muitos dispositivos de consumo são seriamente falhos. Por exemplo, vários roteadores D-Link suportam IPv6 simplesmente encaminhando todo o tráfego sem oferecer nenhum firewall.

Outra consideração: mesmo se o IPv6 travar completamente hoje, ainda levaria mais 20 anos para eliminar o IPv4, devido ao equipamento herdado que as pessoas usarão por muito tempo (ainda vejo servidores Windows 2003 e estações de trabalho Windows XP para não mencionar todas as impressoras, câmeras e gadgets de IoT que não oferecem suporte ao IPv6).

  • CGNat:
    • Vantagem: funciona sem alterações nas instalações do cliente.
    • Desvantagem: suporta apenas conexões de saída.
    • Desvantagem: pode não suportar alguns protocolos.

Eventualmente, o CGNat não será suficiente. Talvez o IPv6 continue assim, mas também é bem possível que acabemos vendo o NAT de nível nacional ou algo assim.

Atualmente, como consultor, muitas vezes tenho que apontar para meus clientes que eles estão expostos ao IPv6 (muitas vezes graças a Teredo). A próxima pergunta será invariavelmente: "quanto custa para consertar isso?" e depois "Quanto custa para bloqueá-lo? O que perdemos se o desativarmos?" Adivinhe qual será a decisão sempre.

Conclusão: para responder sua pergunta, sim, a exaustão 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. Gostaria que o IPv6 fosse bem-sucedido (e gostaria de ver várias melhorias no IPv6). Eu só estou olhando para a situação no momento.


2
O CGN, como qualquer NAT, funciona apenas com TCP, UDP e ICMP, e não com outros protocolos de transporte. Ele também quebra muitos protocolos da camada de aplicativo. O NAT é uma solução feia para tentar estender o IPv4 e realmente sobreviveu à sua utilidade.
Ron Maupin

3
@ supercat, pacotes IP não têm nomes DNS. Esse seria um protocolo diferente. Somente os protocolos de transporte TCP, UDP e ICMP funcionam com o NAPT, outros não. Muitos aplicativos e protocolos da camada de aplicativos não funcionam com o NAPT e exigem hacks feios sobre o hack do NAPT. A premissa do IP é que todo dispositivo final tem um endereço exclusivo, e muitos protocolos foram projetados em torno disso. O IPv6 resolve esse problema, bem como algumas deficiências do IPv4.
21318 Ron Maupin

3
@ supercat, se é realmente assim tão simples, não haveria razão para a enorme base instalada de redes IPX se converter em IPv4. Você poderia fazer o mesmo tipo de coisa entre o IPX e o IPv4, e isso foi feito por um tempo, mas é apenas um clamor.
21418 Ron Maupin

1
@supercat - então, para oferecer suporte a essa rede, precisamos abandonar os padrões existentes e reescrever todos os aplicativos existentes que se conectam diretamente aos endereços? Isso não parece uma boa abordagem para mim.
Jules

2
@KevinKeane Não estou muito surpreso que um roteador antigo de consumidor de 2010 tenha problemas de IPv6. Uma pesquisa de 30 segundos nos resultados de pesquisa do Google indica que eles resolveram esse problema anos atrás.
Michael Hampton

-1

NAT foi o que aconteceu quando o IPv6 era uma idéia, antes que fosse realidade, e a alocação de endereços IP estava se tornando um problema real (alguém se lembra de quando eles estavam distribuindo classes C basicamente para perguntar?) E o mundo real precisava de uma solução nesse meio tempo .

O NAT não é suficiente para a IoT. Se a IoT acontecer, acontecerá com o IPv6. A natureza da IoT está mais alinhada com o funcionamento do mundo dial-up, exceto que haverá várias ordens de magnitude a mais de dispositivos conectados ao mesmo tempo.


2
Em uma pesquisa rápida, o NAT parece ter sido originalmente definido pela RFC 1631 em maio de 1994. O IPv6 é definido na RFC 1883, publicada em dezembro de 1995 como um padrão proposto (que está bastante distante na trilha dos padrões). Não sei onde você define a linha entre "uma idéia" e "realidade", mas quase sempre o código IPv6 em funcionamento quase certamente existia em bancos de testes muito antes da publicação da RFC 1883. Compare isso com a RFC 1918, frequentemente referida, publicada em fevereiro de 1996, alguns meses após a RFC IPv6 inicial.
um CVn 30/01

2
Os padrões são inúteis sem implementação, e uma implementação pela qual consumidores ou empresas estão dispostos a pagar. Testbeds e provas de conceito não contam no mercado. O que eu quero dizer sobre o NAT é que as implementações em funcionamento chegaram ao mercado (e, portanto, ganharam força) porque o hardware existente (e havia uma delas na época) falava IPv4. Portanto, era mais uma questão de "problema resolvido, vamos trabalhar em questões mais urgentes agora".
Xavier

2
@ Xavier: 64K é um limite superior que um dispositivo NAT não pode alcançar. Por um lado, todas as portas baixas abaixo de 1024 são restritas. E a maioria do NAT se limita a um alto intervalo de portas de cerca de 20K portas. E, claro, há um problema de memória: ainda hoje temos roteadores caindo e redefinindo porque alguém tentou abrir 10.000 conexões TCP ao mesmo tempo. Olhando para você, Página inicial do Google.
Zan Lynx

1
@KevinKeane - porque parte da atração para o IOT é poder se conectar externamente aos seus dispositivos. No momento, como configurar o NAT é uma dor que os fabricantes de dispositivos não querem infligir aos consumidores, geralmente fazemos isso por meio de serviços externos de "conexão" fornecidos pelos fabricantes de dispositivos, mas isso não é sustentável a longo prazo . Tudo o que precisa é que um fabricante de alto nível saia do mercado e, de repente, todos ficarão desconfiados de que seus dispositivos continuem funcionando. A única maneira de continuar trabalhando a longo prazo é se a maioria das pessoas tiver IPv6.
Jules

1
@supercat - talvez, mas tão longe que parece ser ainda menos provável de acontecer do que a disponibilidade universal IPv6 ...
Jules

-4

A questão do endereço IPv4 inteiro é bastante complicada. Você pode encontrar um artigo relatando que está esgotado, mas 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 dos países desenvolvidos) com falta deles?

Abaixo está o resultado de um estudo em que nos aventuramos acidentalmente. Ele utiliza nada mais que o protocolo IPv4 original RFC791 e o bloco de endereços 240/4, reservado há muito tempo, mas pouco utilizado, para expandir o pool de IPv4 em 256M vezes. Enviamos um projeto de proposta chamado EzIP (fonético para Easy IPv4) à IETF:

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

Basicamente, a abordagem EzIP não apenas resolverá problemas de falta de endereço IPv4, mas também reduzirá 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. De fato, 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 apreciável e invalidar o mercado de negociar os endereços IPv4.

Qualquer pensamento ou comentário será muito apreciado.

Abe (2018-07-15 17:29)


3
ServerFault não é um IETF WG.
Womble

-5

Honestamente, 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 trabalhei com TI para várias empresas de pequeno e médio porte nos últimos sete anos, e todas as coisas de que você está falando geralmente são apenas configurações padrão. Muito fácil, a menos que você tenha um dispositivo de baixa qualidade ou uma instalaçã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, de um modo 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 quebra de contrato com seu ISP, a menos que você esteja pagando por isso. Claro que você pode fazê-lo, e eles provavelmente não o incomodarão, mas podem.

Encaminhamento de porta e tudo o que não é exatamente complicado. Agora, talvez alguns dispositivos não sejam fáceis de configurar, mas isso não é devido ao IPv4. 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 hoje em dia. Quero dizer, tudo é sincronizado. Você o solta em uma pasta. A menos que você seja nerd como eu e faça tudo através do ssh / sftp (tudo bem, não tudo ). E se você tem algum motivo para realmente executar seu próprio servidor, a hospedagem na nuvem é barata - eu tenho um servidor virtual dedicado que executa o linux em um ssd. A largura de banda é louca rapidamente. Inicializa mais rápido do que eu posso digitar uma seta para cima e pressionar Enter. E é escalável Toda a configuração custa entre 5 e 10 dólares por mês, com backups gratuitos e sem conta de luz.

Realmente não precisa de uma solução de rede ponto a ponto. Até a maioria dos jogos para vários usuários hoje em dia está configurada para interagir através de um servidor intermediário, configurada e pré-configurada. Por outro lado, se o que estou lendo neste post for verdadeiro, a TI estará superlotada e barata se / quando o IPv6 decolar. Até os celulares estão se aproximando da velocidade de fibra. Ou pelo menos cabo.

Se você executa um servidor interno e precisa acessá-lo com o mesmo nome de domínio dentro ou fora da rede, sempre pode falsificar seu endereço usando um roteador baseado em linux e dnsmasq ou entradas personalizadas nos hosts para redirecioná-lo para o endereço local, se você estiver do lado de dentro.

Realmente, não acho que seja realmente desejável que todos os dispositivos tenham seu próprio endereço flutuando aberto na rede. Se alguém quiser ofuscar a si mesmo enquanto o ataca, isso vai acontecer de qualquer maneira. Mas você é um pato sentado, se você está apenas sentado lá bolas na brisa aberta. Não, vou levar meu IPv4 e meu NAT a qualquer dia. Mas é bom que esteja lá.

De qualquer forma, adormecendo agora ... provavelmente mais a dizer, mas vou fazer o check-in amanhã, caso perca alguma coisa. Tenho certeza de que há mais.


12
Uhm, é realmente desejável por causa de conexões mais estáveis, velocidades mais rápidas, internet mais barata (o ISP não precisa manter seus servidores NAT, alocações de blocos de IP por região / cidade e embaralhar coisas para se locomover em horários de pico específicos). Você sabe o quão confuso é para websockets quando um usuário no celular salta de uma torre de celular para outra e obtém um novo IP? Há muito código de compensação, esforço e energia necessários para mantê-lo funcionando. Sua resposta diz: esta torre pode estar perdendo sua fundação, mas ainda não tombou, então está tudo bem.
Tschallacka 29/01

11
Você tem alguns conceitos errados sobre NAT e segurança. Por favor, leia RFC 4864 .
Karl Bielefeldt

4
Nesse ritmo, será mais do que uma geração. O IPv6 tem 20 anos este ano.
Michael Hampton

4
O RFC 2460 foi publicado em dezembro de 1998. Várias partes dele foram publicadas antes deste ponto e houve vários testes. O IPv6 aproximadamente na sua forma atual foi proposto na RFC 1883, que data de dezembro de 1995. Então, você poderia dizer que o IPv6 tem ainda mais de 20 anos. Mas todos consideram o RFC 2460 o ponto em que o IPv6 estava maduro o suficiente para ser implementado.
Michael Hampton

6
BTW, enquanto estou no assunto, você deve estar ciente de que já existem plataformas de jogos apenas para IPv6, como o Xbox One. Um Xbox One com conectividade IPv4 e não IPv6 configura seu próprio túnel Teredo para acessar a Internet IPv6 , o que obviamente traz uma penalidade em latência e confiabilidade. O IPv4 está em um estado bastante triste quando um túnel Teredo é considerado menos confiável do que uma conexão IPv4 típica do consumidor.
Michael Hampton
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.