Por que o IETF escolheu especificamente 192.168 / 16 para ser uma classe de endereço IP privado?


90

Por que a IETF ( Internet Engineering Task Force ) escolheu 192.168/16ser uma classe de endereço IP privado e não outra coisa?

Por que especificamente 192.168/16e 10/8e 172.16/12e não 145.243/16por exemplo?

Existe uma razão pela qual esses endereços IP foram escolhidos como o padrão para endereços IP privados em todas as outras possibilidades?



32
A RFC 1918 não contém explicações sobre por que especificamente essas redes foram escolhidas, Akash. Daí a pergunta do questionador.
19414 JdeBP

1
Eu estava errado sobre isso ser irresponsável. Consegui responder sua pergunta quase completamente, usando RFCs. Mas 1918 não é o mais importante para responder a pergunta ...
Michael Hampton

Respostas:


89

Eu sei quem escolheu esses intervalos de endereços. Infelizmente, ele está morto, então não posso perguntar exatamente por que ele os escolheu, mas posso fazer algumas suposições bem informadas.

Não há muito namoro online antes de meados dos anos 90, quando a Internet realmente começou a decolar. A história da Internet existe principalmente nas RFCs que a definem, que datam de 1969 , no início da ARPANET. Através deles, é possível assistir o progresso da Internet de uma rede iniciante de alguns mainframes primitivos, projetados por algumas das mentes mais brilhantes da época, para a rede que mal podemos imaginar vivendo sem hoje.

Essa resposta se baseia quase inteiramente nessas RFCs e, em parte, na minha experiência pessoal como eu estava na Internet nesta época.


Primeiro, o IETF não escolheu esses intervalos de endereços IP ou quaisquer outros. A alocação de endereços de uso especial é atualmente e sempre foi um trabalho da Autoridade de Números Atribuídos à Internet .

A IANA sempre foi um papel , e não uma organização específica, e esse papel mudou de mãos exatamente uma vez. Atualmente, ela é mantida pela ICANN, mas de 1972 até sua morte em 1998, quando essa organização foi criada para substituí-lo, a IANA era essencialmente um homem, Jon Postel . Obviamente, ele chamou o papel de czar dos números de soquete , uma tarefa necessária que ele assumiu porque precisava ser feita. Ele terminou o czar de praticamente todos os números que podiam ser atribuídos: endereços, números de protocolos, portas, o nome dele, principalmente porque ele estava disposto a fazê-lo, e quando a Internet se abriu para o comércio públicoele faz isso há mais de 20 anos. Ele atribuiu os números e o Registro da Internet (então SRI-NIC, que foi expandido para uma coleção distribuída de registros em todo o mundo) os publicou.

A última RFC do SRI que mostra uma lista de atribuições de endereços da Internet foi a RFC 1166 de 1990. Como é uma lista muito extensa, não surpreende que esses dados tenham sido movidos para bancos de dados online. Comparando-o ao seu antecessor, o RFC 1117 mostra a taxa de expansão da Internet mesmo assim, anos antes de ser aberta ao público.

Portanto, agora estamos em posição de entender um pouco melhor os intervalos de endereços na RFC 1918 . Esta é realmente a segunda revisão da RFC; o primeiro foi o RFC 1597 , publicado quase dois anos antes em março de 1994. Em sua refutação pouco conhecida, o RFC 1627 , foram apresentados os argumentos contemporâneos contra espaços de endereços privados. A RFC 1627 também menciona quem atribuiu os três espaços de endereço.

Eles foram designados pela IANA, ou seja, Jon Postel, a pedido dos autores da RFC 1597, e, para acreditar na queixa na RFC 1627, ele o fez por meio de canais externos, e não pelos processos abertos usuais. Você pode ver que RFC 1597 em si foi direto ao status RFC sem os habituais anteriores Internet-Rascunhos , por isso também foi aprovado por meio de canais, novamente por Postel, que também era editor RFC no momento . Portanto, talvez nunca seja possível responder a essa pergunta de maneira conclusiva.

Agora, por que ele escolheu esses três intervalos de endereços, deixe-me voltar a atenção para as RFCs 1166 e 1117 do SRI, que tinham as atribuições de intervalo de endereços IP então vigentes. Nos dois, você notará que a rede 10 ainda estava alocada para a extinta ARPANET, que foi encerrada em 1990 . Postel, em sua função de IANA, saberia que esse intervalo não estava mais em uso e poderia ser reatribuído. Afirmo que Postel escolheu a rede 10 porque sabia que ela estava disponível e não estava em uso.

Da mesma forma, espero que Postel tenha escolhido 192.168 porque, no momento em que ele fez a escolha, era a próxima rede disponível, ou quase a próxima disponível, a ser atribuída a partir do antigo espaço da Classe C. Provavelmente, isso não pode ser provado de uma maneira ou de outra, mas o ritmo das atribuições de endereços mostradas nas RFCs sugere fortemente que elas estariam nessa vizinhança geral por volta de 1993-1994, quando as atribuições foram feitas. (Os endereços em 192.159 estavam sendo atribuídos em 1992. Não há datas disponíveis para atribuições em 192.160-192.167, pois em algum momento elas foram realocadas para o RIPE.)

Responder a esta pergunta para 172.16-172.31 é mais difícil. Nada que eu encontrasse sugere por que esse intervalo foi selecionado. As tarefas no antigo espaço da Classe B ainda não haviam chegado tão alto, até onde posso descobrir. Só posso especular que a IANA jogou um dardo em um alvo, jogou dados ou puxou o número de suas regiões inferiores.


Finalmente, uma nota sobre Jon Postel. Apesar da maneira aparente pela qual essa RFC foi criada totalmente sem a contribuição (inicial) da comunidade, não pretendo sugerir isso, e isso não deve ser interpretado como, Jon Postel, de alguma forma, executou o papel da IANA de maneira ruim ou injusta. Ele foi uma das influências mais fortes no início da Internet, e você ainda sente essa influência hoje em dia toda vez que vê o mecanismo dos bastidores da Internet, mas sempre se preocupou em fazer o trabalho corretamente. Para citar uma lembrança :

Não há glória em administrar e operar. Muito pelo contrário. As pessoas percebem quando é mal feito, mas raramente elogiam quando bem feito. Pessoas em cargos administrativos frequentemente se tornam burocratas mesquinhos. Como há tão pouca recompensa no trabalho, eles artificialmente a tornam uma base de poder. Por isso, confundiu alguns que ouviram Jon referido como os números da Internet "czar". Eles não perceberam que a comunidade atribuiu o título a Jon por afeto e profunda gratidão por ele ter pedido os serviços essenciais de infraestrutura. Em particular, a comunidade usou esse termo com pleno conhecimento de que Jon assumiu sua posição como uma confiança, e não como uma oportunidade de poder pessoal. Sempre soubemos que seus pontos de vista vinham de crenças legítimas e nunca tivemos que nos preocupar que ele estivesse de alguma forma considerando uma vantagem política ou pessoal. Podemos não concordar com ele, mas sempre soubemos que era motivado pela preocupação de que a coisa certa fosse feita.


6
Deve ter sido um show difícil para Jon. É aqui que temos a expressão "Going Postel"? :-p
tudor

5
Jon Postel é um dos meus heróis de longa data. Ele estava sempre no back-end, mantendo os cientistas mais famosos trabalhando juntos em direção a um objetivo comum. O pai da governança da Internet.
Frank Thomas

4
"Não há muito namoro online antes de meados dos anos 90" - Sem brincadeira, o match.com não foi registrado até 1998. Não? ... eu vou pegar meu casaco.
Anônimo

1
Uma nova publicação do NANOG confirma que eles eram alocações comuns do "próximo disponível".
grawity

30

Porque fazia sentido na época? :-D

Lembre-se, quando os intervalos de endereços IP privados foram atribuídos, havia vários problemas que os engenheiros de rede tinham que enfrentar: Alguns dos roteadores mais poderosos da época tinham tanto poder de CPU e armazenamento de RAM quanto as calculadoras gráficas de bolso de hoje - e algumas dos que hoje ainda circulam em torno dos roteadores dos anos anteriores (lembro-me de quando a velocidade da CPU era medida em kilohertz e o armazenamento de RAM era medido em kilobytes, não os giga * como são hoje!). A Internet estava crescendo rapidamente, o IPv4o espaço de endereçamento era limitado e parecia que chegaria ao fim no ano 2000, mais ou menos, etc. Portanto, muitos intervalos de endereços IP já foram atribuídos e eles não queriam pedir às empresas que devolvessem os intervalos de endereços IP apenas para poderem atribuí-los novamente a intervalos privados. Eles também queriam facilitar ao máximo o trabalho das empresas com os intervalos privados - poucas empresas teriam cooperado se tivessem que investir muito dinheiro para fazer suas redes lidar com uma ou duas dúzias de intervalos / IP endereços aqui e ali.

Esta parte é, sem dúvida, uma adivinhação da minha parte, mas baseada principalmente na lógica e na experiência na criação de redes. Eles provavelmente reuniram uma lista de todos os números de redes não atribuídos e procuraram um padrão distinto que atendesse aos critérios desejados: Uma única classe Os endereços A (números de rede que possuem um bit alto de 0xxxxxxx no número de rede eram Classe A), 16 endereços de Classe B (números de rede 10xxxxxx) e 256 endereços de Classe C (números de rede 110xxxx binários). Os endereços das classes B e C também devem ser consecutivos . (A escolha de 16 e 256 provavelmente foi parcialmente arbitrária - depois de fazer essas coisas por um tempo, você tende a pensar em potências de 2 - e provavelmente em parte porque era o que o achado estava disponível para reserva.)

A partir disso, eles provavelmente selecionaram os intervalos finais entre os endereços disponíveis, o que permitiria aos fabricantes de roteadores fazer um teste bit a bit simples no endereço para determinar se deveria encaminhar / encaminhar / descartar o pacote. Também existem algumas propriedades dos padrões de bits que ajudam a criar tabelas NAT compactas. O endereço 10.xyz é óbvio, pois só precisa corresponder a um número de rede. O 172.16.yz a 172.32.yz tem o padrão de que, se você criar uma tabela com quatro bits de ordem inferior, fazendo referência cruzada aos quatro bits de ordem superior, todo o intervalo será preenchido em uma única linha da tabela, sem se dividir em duas linhas - ou seja, o segundo octeto é sempre 0001xxxx (binário). Em 192.168.yz, o binário para 168 é 10101000 - ou seja, os três bits mais baixos são sempre 0 e os 5 bits mais altos alternam 1 e 0.

Embora isso possa parecer arbitrário, se você já fez alguma programação em linguagem de máquina ou decodificação de microcódigo, esse tipo de padrão permite testar apenas alguns bits para fazer uma determinação pública / privada, sem ter que decodificar o endereço IP inteiro primeiro. Isso permitiria que os roteadores processassem esses endereços rapidamente, sem precisar manter extensas tabelas de pesquisa na memória. Assim, o roteador pode enviar um pacote de rede privado de volta para a rede privada sem decodificá-lo completamente primeiro, eliminando preciosos ciclos de relógio da velocidade do roteador e da rede.

Se você estiver curioso, veja como a transmissão de dados seriais (como um UART) lida com cada byte de dados: ele só pode enviar / receber um único bit de cada vez, na velocidade do relógio de controle e geralmente enquadra os dados em bits adicionais, como bits de paridade e "sincronização". Seria muito demorado tentar calcular coisas como paridade em um byte inteiro de uma só vez; portanto, ele mantém um bit especial que cada ciclo de clock. Esse bit é modificado pelo próximo bit que é deslocado para dentro / fora do registro de envio / recebimento. Assim que o byte inteiro é enviado / recebido, o valor deixado no bit de paridade já está correto sem a necessidade de recalculá-lo. O conceito é mais ou menos "faça o trabalho ao mesmo tempo que você está fazendo outra coisa", no caso de um chip serial, está calculando a paridade ao mesmo tempo em que está enviando / recebendo. Para um roteador / switch,

Além disso, isso é apenas lógica / adivinhação da minha parte, com base em 25 anos de realização desse tipo de trabalho. Não sei se alguma vez saberemos as razões exatas por trás dos números finais escolhidos, pois não recordo nenhum artigo / RFC / etc. sempre dando a lógica completa. O mais próximo que vi são apenas alguns comentários sugerindo que os intervalos escolhidos devem tornar relativamente fácil e eficiente para as empresas usá-los com o mínimo esforço / investimento / reengenharia.


6
Isso não parece explicar a escolha de 168 em particular. Não vejo nenhuma razão para decodificar 10101000 do que 10101010 ou 10101001 - em ambos os casos, é necessário corresponder todos os 8 bits antes que se saiba que o endereço pertence à rede privada. Intuitivamente, parece mais provável que 192.168 tenha sido simplesmente o primeiro bloco de tamanho apropriado disponível quando a alocação foi feita, do que o padrão de bits específico 10101000, de alguma forma, sendo mais fácil de decodificar do que outros padrões do mesmo comprimento.
Henning Makholm

@HenningMakholm, o moderno equipamento de rede usa muitos circuitos integrados específicos para aplicativos ASICs, que executam o processamento de entradas no hardware. um registro simples pode ser implementado no hardware para verificar um padrão de bits comum, de modo que apenas uma instrução de montagem seja necessária para analisá-lo. Não estou dizendo que os pensamentos dos CMs são o que os designers do rfc1918 estavam pensando (não podemos saber porque eles não incluíram essa informação), mas é uma possibilidade intrigante.
27414 Frank Frank Thomas

2
@FrankThomas: Você está dizendo que a correspondência para 168 seria mais fácil de produzir um circuito ASIC do que a correspondência para alguma outra constante de 8 bits seria? Não sou designer de hardware, mas acho difícil de acreditar.
Henning Makholm

2
Não há exigência no protocolo para que os roteadores processem essas redes de qualquer maneira especial; portanto, quase toda essa resposta é irrelevante. Lembre-se de que a RFC 1918 não especificou o NAT e previa que esses endereços seriam puramente internos, sem nenhuma maneira de acessar a Internet. NAT veio um pouco mais tarde, e não foi realmente especificado até RFC 2663.
Michael Hampton

2
@Frank Não faço muito com verilog ou VHDL há muito tempo, mas não acho que sua lógica seja verdadeira. Pelo menos a maneira óbvia (e eficiente) de como eu implementaria a igualdade no hardware não se importa com nenhum padrão. Existem alguns ISAs que só podem gerar padrões específicos para imediatos lógicos (o ARMv8 para nomear um realmente novo), mas é isso.
Voo

21

Na Internet primordial , a rede agora indicada 10.0.0.0/8 foi alocada para a ARPANET . Quando a IETF e a IANA começaram a atribuir intervalos de endereços privados, a ARPANET estava extinta e seu antigo espaço de endereço estava disponível para uso privado.

Os outros dois intervalos disponibilizaram redes Classe B e Classe C para IPs particulares, além da mencionada Classe A.


15

Porque 192 começa com 11xxxxxx em binário, indicando uma rede de classe C. É o número mais baixo que começa com dois 1s consecutivos. As classes A têm 0 como os bits de ordem mais alta e as classes B têm 10.

A RFC 1918, que define os intervalos de IP privados, não esclarece sobre esse ponto; portanto, não há resposta definitiva sobre por que eles escolheram 0,168 para o bloco de 16 bits, mas eu afirmo que isso ocorreu porque o RFC não foi lançado até 1996, após um grande número de registros já ter ocorrido. como 192 é o primeiro bloco de 8 bits nas alocações de classe C, é provável que muitos dos endereços já tenham sido utilizados. 168 pode ter sido o primeiro disponível.

Lembre-se também de que algumas dessas opções são arbitrárias. Observe que o intervalo da classe B rfc1918 é 172,16 - 172,31? Não consigo pensar no motivo do 172, mas tenho certeza de que eles escolheram usar 16 classes Bs, de modo que tinham um bloco de 1 milhão de endereços contíguos (1048576).

Às vezes, os protocolos são exatamente assim. alguém teve que fazer uma escolha, e eles fizeram. por um tempo, o kernel do linux ficou limitado a um máximo de 1024 CPUs por sistema e, eventualmente, eles tiveram que emitir um patch, depois que alguns supercomputadores tiveram problemas. quem decidiu usar o 1024 provavelmente não tinha um bom motivo para fazer isso, além de precisar de um valor, e 1024 é agradável e redondo.


1
Um bom ponto. Especialmente combinado com o histórico do post de Darth Androids e talvez algumas informações adicionais sobre os primeiros bits das outras classes.
Hennes

9
Mas por que 192.168?
user253751

14

Este é um remanescente do Classful Networking , onde o intervalo de endereços IPv4 foi subdividido em classes:

  • Classe A: 0.0.0.0 - 127.255.255.255 / 255.0.0.0
  • Classe B: 128.0.0.0 - 191.255.255.255 / 255.255.0.0
  • Classe C: 192.0.0.0 - 223.255.255.255 / 255.255.255.0
  • Classe D: 224.0.0.0 - 239.255.255.255 (multicast)
  • Classe E: 240.0.0.0 - 255.255.255.255 (reservado)

Desde então, passamos (em 1993) para o Roteamento entre domínios sem classe , no entanto, as classes ainda têm seu legado em vários lugares (a rede 127 é "casa / loopback" - 127.0.0.1 alguém? Nos roteadores, a rede 10 é comum em hardware de rede mais "corporativo" e o multicast ainda é multicast.


16
O questionador parece estar perguntando, no entanto, por que essas redes específicas em cada classe foram escolhidas, como fez em outro site da WWW e em outro StackExchange , cuja resposta não é abordada. user46971 atingiu a unha na cabeça.
JdeBP

1
Essa resposta do SE é tão boa que acho que talvez essa pergunta deva ser migrada e depois marcada como duplicada. É realmente mais sobre rede do que sobre o uso geral do computador.
trlkly

3

A RFC explica a razão pela qual escolhemos três faixas da "Classe A, B e C", respectivamente: o CIDR havia sido especificado, mas não havia sido amplamente implementado. Havia uma quantidade significativa de equipamentos por aí que ainda eram "de classe".

Tanto quanto me lembro, a escolha dos intervalos particulares foi a seguinte:

10/8: o ARPANET acabara de ser desligado. Um de nós sugeriu e Jon considerou isso uma boa reutilização desse bloco de endereços "histórico". Também suspeitávamos que a "rede 10" pudesse ter sido codificada em alguns lugares; portanto, reutilizá-la para o espaço de endereço privado e não no roteamento entre AS pode ter a pequena vantagem de manter essa bobagem local.

172.16 / 12: o menor não alocado / 12 no espaço da classe B.

192.168 / 16: o menor / não alocado / 16 da classe C, bloco 192/8.

Em resumo: a IANA alocou esse espaço da mesma forma que teria para qualquer outro propósito. Como a IANA, Jon era muito consistente, a menos que houvesse um motivo realmente bom para ser criativo.

Daniel (co-autor de RFC1918)

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.