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


Por que o Força-tarefa de engenharia da Internet (IETF) escolher 192.168/16 ser uma classe de endereço IP privado e não outra coisa?

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

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


84


origem


tools.ietf.org/html/rfc1918 - Akash
RFC 1918 não contém explicação sobre porque especificamente estes  redes foram escolhidas, Akash. Daí a pergunta do questionador. - JdeBP
Eu estava errado sobre isso ser irrespondível. Eu pude responder sua pergunta quase completamente, usando RFCs. Mas 1918 não é o mais importante para responder a pergunta ... - Michael Hampton


Respostas:


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

Não há muito namoro on-line antes de meados dos anos 90, quando a Internet realmente começou a decolar. Que história da Internet existe principalmente na RFCs que o definem, que remontam a 1969, no início da ARPANET. Através deles, você pode assistir à evolução da Internet a partir de uma rede incipiente de alguns mainframes primitivos, projetados por algumas das mentes mais brilhantes da época, para a rede que dificilmente podemos imaginar viver sem hoje.

Essa resposta é quase inteiramente extraída dessas RFCs e, em parte, da minha experiência pessoal, como eu estava na Internet nessa época.


Primeiro, o IETF não selecionou esses intervalos de endereços IP ou quaisquer outros. Alocação de endereços de uso especial está atualmente e sempre tem sido o trabalho do Internet Assigned Numbers Authority.

A IANA sempre foi uma Função, em vez de uma organização específica, e esse papel mudou de mãos exatamente uma vez. Atualmente, ele é mantido 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. Claro, ele primeiro chamou o papel czar de números de soquete, uma tarefa necessária, ele assumiu porque precisava ser feito. Ele acabou o czar de praticamente todos os números que poderiam ser atribuídos: endereços, números de protocolo, portas, o nome dele, em grande parte porque ele estava disposto a fazê-lo, e no momento em que a Internet aberto ao comércio público ele fazia isso há mais de 20 anos. Ele atribuiu os números, e o Registro da Internet (então SRI-NIC, isso foi expandido para um coleção distribuída de registros em todo o mundo) publicou-as.

A última RFC do SRI mostrando uma lista de atribuições de endereços da Internet foi RFC 1166 de 1990. É uma lista muito longa, por isso não deveria ser surpreendente que esses dados tenham sido movidos para bancos de dados online. Comparando-o ao seu antecessor RFC 1117 mostra a taxa de expansão da Internet até então, anos antes de ser aberta ao público.

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

Eles foram designados pela IANA, isto é, Jon Postel, a pedido dos autores da RFC 1597, e se a queixa na RFC 1627 deve ser acreditada, ele o fez por meio de canais anteriores ao invés dos processos abertos habituais. Você pode ver que o próprio RFC 1597 foi direto para o status RFC sem o habitual precedente Rascunhos da Internet, por isso também foi aprovado via canais de volta, novamente por Postel, que também era editor da RFC na época. Portanto, talvez nunca seja possível responder a essa pergunta de forma conclusiva.

Agora, por que ele escolheu esses três intervalos de endereços, deixe-me voltar sua atenção para os RFCs 1166 e 1117 do SRI, que tinham as atribuições de intervalo de endereços IP atuais. Em ambos, você notará que a rede 10 ainda estava alocada ao defunto ARPANET, que teve encerrado em 1990. Postel, em seu papel como IANA, saberia que esse intervalo não estava mais em uso e poderia ser transferido. Eu 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 o 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 do antigo espaço da Classe C. Isso provavelmente não pode ser provado de uma forma ou de outra, mas o ritmo das atribuições de endereços mostradas nas RFCs sugere fortemente que eles teriam estado nessa vizinhança geral por volta de 1993-1994 quando as designaçõ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, já que elas foram realocadas para RIPE em algum momento.

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


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

Não há glória em fazer administração e operações. Muito pelo contrário. As pessoas percebem quando isso é mal feito, mas raramente oferecem elogios quando isso é feito bem. Pessoas em cargos administrativos muitas vezes se tornam pequenos burocratas. Como há tão pouca recompensa no trabalho, eles artificialmente fazem disso uma base de poder. Por isso, confundiu alguns que ouviram Jon se referir aos números da Internet como "czar". Eles não perceberam que a comunidade concedeu o título a Jon por afeição e profundo apreço por ele ter trazido ordem para serviços essenciais de infra-estrutura. Em particular, a comunidade usou esse termo com pleno conhecimento de que Jon assumiu sua posição de 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 nos preocupávamos com o fato de ele estar, de alguma forma, considerando vantagem política ou pessoal. Podemos não concordar com ele, mas sempre soubemos que era motivado primeiro pela preocupação de que a coisa certa fosse feita.


83



Isso deve ter sido um show difícil para Jon. É onde obtemos a expressão "Going Postel"? :-p - tudor
Jon Postel é um dos meus heróis de longa data. Ele estava sempre no backend, mantendo os cientistas mais famosos trabalhando juntos em direção a um objetivo comum. O pai da governança da Internet. - Frank Thomas
"Não há muito namoro online antes de meados dos anos 90" - Sem brincadeira, match.com não foi registrado até 1998. Não? ... vou pegar meu casaco. - Anonymous
Um fresco Postagem NANOG confirma que eram alocações comuns "disponíveis". - grawity


Porque fazia sentido na época? :-D

Lembre-se, quando os intervalos de endereços IP privados foram atribuídos, havia vários problemas com os engenheiros de rede: alguns dos roteadores mais poderosos da época tinham o mesmo poder de CPU e armazenamento de RAM que as calculadoras gráficas de bolso de hoje - e alguns dos que ainda hoje rodam em torno dos roteadores de anos anteriores (lembro-me de quando a velocidade da CPU era medida em kilohertz e o armazenamento da RAM era medido em kilobytes, e não os da giga * como hoje em dia!). A Internet estava crescendo rapidamente, o IPv4 o espaço de endereços era limitado e parecia que ia acabar no ano 2000, etc. Assim, muitos intervalos de endereços IP já foram atribuídos, e eles não queriam ter que pedir às empresas para devolverem os intervalos de endereços IP apenas para que pudessem reatribuí-los a intervalos privados. Eles também queriam tentar facilitar o máximo possível as empresas para trabalhar com as áreas privadas - poucas empresas teriam cooperado se tivessem que investir muito dinheiro para fazer com que suas redes lidassem com uma ou duas dúzias de faixas / IP. endereços aqui e ali.

Essa parte é uma adivinhação da minha parte, mas baseada amplamente na lógica e na experiência de configuração de redes. Eles provavelmente reuniram uma lista de todos os números de rede não atribuídos e procuraram um padrão distinto que atendesse aos critérios desejados: A (números de rede que têm um bit alto de binário 0xxxxxxx no número da rede eram Classe A), 16 endereços de Classe B (números de rede 10xxxxxx binário) e 256 de Classe C (números de rede 110xxxx binários). Os endereços das classes B e C devem ser todos consecutivo, também. (A escolha de 16 e 256 foi provavelmente parcialmente arbitrária - depois de fazer essas coisas por um tempo, você tende a começar a pensar em poderes de 2 - e provavelmente em parte porque era o que eles achavam que era acessível para reserva.)

A partir disso, eles provavelmente selecionaram os intervalos finais a partir dos endereços disponíveis, o que permitiria que os fabricantes de roteadores fizessem um simples teste bit-wise no endereço para determinar se deveria rotear / encaminhar / descartar o pacote. Existem também algumas propriedades dos padrões de bits que eu posso ver ajudando a construir tabelas NAT compactas também. O endereço 10.x.y.z é óbvio, uma vez que ele só precisa corresponder a um número de rede. O 172.16.yz para 172.32.yz tem o padrão que, se você construir uma tabela com os quatro bits de ordem baixa, fazendo referência cruzada aos quatro bits de alta ordem, o intervalo inteiro preencherá uma única linha da tabela, sem dividir em duas linhas - Ou seja, o segundo octeto é sempre 0001xxxx (binário). Em 192.168.y.z, o binário para 168 é 10101000 - ou seja, os três bits inferiores são sempre 0 e os 5 bits superiores alternam entre 1 e 0.

Embora possam parecer arbitrários, se você já fez alguma programação em linguagem de máquina ou decodificação de microcódigo, esse tipo de padrão permite que você teste apenas alguns bits para determinar o público / privado 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 poderia empurrar um pacote de rede privada de volta para a rede privada sem decodificá-lo totalmente primeiro, reduzindo os preciosos ciclos de clock da velocidade do roteador e da rede.

Se você está curioso, veja como a transmissão de dados serial (como um UART) manipula cada byte de dados: Ele só pode enviar / receber um único bit de cada vez, na velocidade do relógio de controle, e geralmente emoldura os dados em bits adicionais, como bits de paridade e "sync". Seria muito demorado tentar calcular coisas como paridade em um byte inteiro de uma vez, então, ao invés disso, 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 ter que recalculá-lo. O conceito é mais ou menos "fazer o trabalho ao mesmo tempo que você está fazendo outra coisa", no caso de um chip serial, é calcular a paridade ao mesmo tempo que ele está enviando / recebendo. Para um roteador / switch, você pode obter um desempenho mais alto se já estiver decodificando o endereço IP, já que cada bit do endereço vem do cabo e possivelmente já sabe para onde enviar o pacote antes mesmo de terminar de ser lido da rede cabo!

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


29



Isso não parece explicar a escolha de 168 em particular. Não vejo qualquer razão pela qual 10101000 seria mais fácil de decodificar do que 10101010 ou 10101001 - em ambos os casos, é preciso combinar todos os 8 bits antes que alguém 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 que estava disponível quando a alocação foi feita, do que o padrão de bit 10101000 de alguma forma sendo mais fácil de decodificar do que outros padrões de mesmo tamanho. - Henning Makholm
@HenningMakholm, equipamento de rede moderno usa muitos ASICs, circuitos integrados específicos da aplicação, que realizam o processamento de entradas em hardware. um registro simples poderia ser implementado em hardware para verificar um padrão de bit comum, de tal forma que apenas uma instrução de montagem seja necessária para analisá-lo. Eu não estou dizendo que os pensamentos de CMs são o que os designers do rfc1918 estavam pensando (nós não podemos saber porque eles não incluíram essa informação), mas é uma possibilidade intrigante. - Frank Thomas
@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
Não há exigência no protocolo para que os roteadores processem essas redes de maneira especial, de modo que quase toda essa resposta é irrelevante. Lembre-se que a RFC 1918 fez não especifique NAT, e imaginou que esses endereços seriam puramente internos, sem nenhum meio de acessar a Internet. O NAT veio um pouco mais tarde e não foi especificado até o RFC 2663. - Michael Hampton
@Frank Eu não fiz muito com verilog ou VHDL por muito tempo, mas não acho que sua lógica seja verdadeira. Pelo menos a maneira óbvia (e eficiente) de implementar a igualdade no hardware não se preocupa com nenhum padrão. Existem alguns ISAs que podem gerar apenas padrões específicos para lógicos imediatos (ARMv8 para nomear um realmente novo), mas é sobre isso. - Voo


No Internet primordial, a rede agora denotada 10.0.0.0/8 foi alocada para o ARPANET. No momento em que o 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.

As outras duas faixas disponibilizavam as redes Classe B e Classe C para IPs privados, além da Classe A.


20





Porque 192 começa com 11xxxxxx em binário, indicando um classe C rede. É o menor número que começa com dois 1's consecutivos. As classes A têm 0 como seu (s) bit (s) mais alto (s) e as classes B têm 10.

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

Também tenha em mente que algumas dessas escolhas são arbitrárias. Observe que o intervalo de classe B do rfc1918 é 172.16 - 172.31? Eu não consigo pensar no motivo de 172, mas tenho certeza que eles escolheram usar 16 classes Bs, então eles tinham um bloco de 1 milhão de endereços contíguos (1048576).

Às vezes, os protocolos são assim. alguém teve que fazer uma escolha, e eles conseguiram. Por um tempo, o kernel do Linux foi 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 1024 provavelmente não tinha uma boa razão para fazê-lo senão que ele precisava de um valor, e 1024 é bom e redondo.


14



Um bom ponto. Especialmente combinado com o fundo da postagem Darth Androids e talvez algumas informações adicionais sobre os primeiros bits das outras classes. - Hennes
Mas por que 192.168? - user20574


Este é um remanescente de Rede de Classes, 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, nos mudamos (em 1993) para Encaminhamento inter-domínio sem classe, no entanto, as classes ainda têm seu legado em vários lugares (a rede 127 é "home / loopback" - 127.0.0.1 qualquer pessoa ?, 192.168.X é comum para roteadores domésticos, a rede 10 é comum em hardware de rede mais "empreendedor", e multicast ainda é multicast.


13



O questionador parece estar perguntando, estes em particular redes de cada turma foram escolhidas, essa pessoa fez em outro site da WWW e essa pessoa fez em outro StackExchange, que sua resposta não resolve. user46971 atingiu o prego na cabeça. - JdeBP
Essa resposta do SE é tão boa que acho que talvez essa questão deva ser migrada e marcada como duplicada. É mais sobre rede do que sobre o uso geral do computador. - trlkly


O RFC explica o motivo pelo qual escolhemos três intervalos de "Classe A, B & C "respectivamente: o CIDR foi especificado, mas não foi amplamente implementado. Havia uma quantidade significativa de equipamentos por aí ainda era "classful".

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

10/8: a ARPANET acaba de ser desligada. Um de nós sugeriu isso e Jon considerou isso uma boa reutilização desse bloco de endereços "histórico". Nós também suspeitava que "net 10" poderia ter sido codificado em alguns lugares, então reutilizá-lo para o espaço de endereço privado, em vez de em roteamento inter-AS pode ter a ligeira vantagem de manter tal tolice local.

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

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

Em resumo: a IANA alocou esse espaço exatamente como teria para qualquer outra finalidade. Como a IANA, Jon era muito consistente, a menos que houvesse Uma boa razão para ser criativo.

Daniel (co-autor do RFC1918)


2