Disclaimer: este post não tem foco. ¡Viva Zapata!
Tudo começou quando eu meditava sobre o IPv6. A versão atual do IP (o IPv4, definido em 1981) usa endereços de 32 bits, o que dá cerca de 4 bilhões de endereços possíveis. Esse número já é pouco por si só (não dá para entregar um IP para cada pessoa no mundo, por exemplo), e para piorar a situação a galera dos anos oitenta distribuiu faixas de IPs de uma maneira ridiculamente esbanjadora (a sua máquina, por exemplo, possui nada menos do que 16 777 214 endereços locais: todos os endereços de host de 127.0.0.1 a 127.255.255.254). A fonte infinita de IPs começou a acabar no ano passado, com a exaustão dos IPs do IANA (órgão mundial responsável pela alocação de endereços IP, entre outras coisas) e da APNIC (organização à qual o IANA delega a alocação de IPs na Ásia e Oceania); os IPs das outras regiões hão de acabar em breve. Vale notar que já se está fazendo altas gambiarras há anos para contornar a exaustão, como o uso de NAT, que permite que várias máquinas em uma rede privada compartilhem do mesmo IP na Internet. O NAT destrói o princípio de dar um endereço único para cada máquina, e é o responsável por bagunçar seus torrents e complicar sua vida ao tentar acessar sua máquina de casa remotamente.
A solução em vias de adoção é o IPv6, definido em 1998. O IPv6 usa endereços de 128 bits, o que nos dá cerca de 340 undecilhões de endereços possíveis. (2128 = 340 282 366 920 938 463 463 374 607 431 768 211 456.) O espaço de endereçamento não vai acabar tão cedo, mesmo com os desperdícios que já se apressaram em fazer, a menos que comecemos a dar IPs únicos para moléculas.
Mas de qualquer forma, eu me perguntava: por que 128 bits? Por que não tornar o endereço um valor de tamanho arbitrário? Teríamos uma quantidade infinita de endereços, e evitaríamos desperdício com um campo mais longo do que precisa ser. A máquina que processa o pacote IP teria mais trabalho para decodificar o pacote, mas a diferença não é necessariamente significativa; na prática, a máquina/roteador teria um tamanho limite interno (e.g., 128 bits), e ao ler o pacote extrairia o endereço e o colocaria em um registrador/região de memória de tamanho fixo. A vantagem aqui é que se no futuro quisermos mais IPs, o protocolo permanece inalterado: quando esgotarmos o espaço de endereços de 64 bits, gradualmente atualizamos a infra-estrutura da rede para aumentar o limite de 128 para 256 bits; quando consumirmos 128, aumentamos de 256 para 512. Aumentando o limite (bem) antes do necessário, garantimos que o sistema que estamos construindo hoje funcionará corretamente pelos próximos dez ou vinte anos. (Você está escrevendo hoje os sistemas velhos de daqui a vinte anos. Já parou para pensar nisso?)
Um possível problema com simplesmente atribuir um natural a cada máquina é o roteamento: as tabelas de roteamento para faixas de números tenderiam a crescer cada vez mais. Uma solução seria usar valores estruturados hierarquicamente: o primeiro byte escolheria a sub-rede apropriada no nível mais alto da hierarquia, o segundo byte a sub-rede dentro dessa sub-rede, e assim por diante, com quantos níveis de hierarquia se quisesse. O caminho de roteamento está implícito na estrutura do endereço. O problema é que esgotada a capacidade de um nível de hierarquia, não é mais possível expandir o espaço de endereçamento desse nível sem renumerar as máquinas existentes (reorganizando a hierarquia para adicionar mais um nível, por exemplo). A menos que cada sub-rede também seja indicada com um número de tamanho arbitrário; um endereço, então, é uma lista de números naturais. A parte divertida é que você receberia do seu provedor um prefixo da lista, e poderia criar uma hierarquia qualquer sob esse prefixo, visível na Internet. Endereços de tamanho variável com campos de tamanho variável não parecem algo particularmente amigável à performance, entretanto.
Pelo visto a idéia de endereço de tamanho variável é tão antiga quanto a Internet. Segundo Vint Cerf, segundo a Wikipédia:
The decision to put a 32-bit address space on there was the result of a year's battle among a bunch of engineers who couldn't make up their minds about 32, 128, or variable-length. And after a year of fighting, I said—I'm now at ARPA, I'm running the program, I'm paying for this stuff, I'm using American tax dollars, and I wanted some progress because we didn't know if this was going to work. So I said: OK, it's 32-bits. That's enough for an experiment; it's 4.3 billion terminations. Even the Defense Department doesn't need 4.3 billion of everything and couldn't afford to buy 4.3 billion edge devices to do a test anyway. So at the time I thought we were doing an experiment to prove the technology and that if it worked we'd have opportunity to do a production version of it. Well, it just escaped! It got out and people started to use it, and then it became a commercial thing. So this [IPv6] is the production attempt at making the network scalable.
Na leitura page-down-driven que eu tinha feito desse artigo, entretanto, não tinha visto essa passagem. O que foi muito bom, pois eu saí a procurar se alguém já tinha proposto alguma coisa similar no mundo. Caí nesta página. O cara fala muito e diz pouco (ou eu estava de mau humor quando li esta e outras páginas dele). Ele propõe basicamente a mesma coisa que eu propus. Além disso ele propõe uma arquitetura chamada Nimrod (que não tem nada que ver com a linguagem de programação Nimrod), que implementa a idéia e resolve um outro problema que eu nunca tinha parado para pensar sobre: que a arquitetura IP mistura a noção de endereço (o meio para atingir uma máquina) com a noção de identificador da máquina. Se uma máquina tem mais de uma placa de rede, ela terá dois IPs, e não terá um identificador único. Se a máquina troca de IP, ela perde sua identidade, e as conexões abertas são perdidas.
Na minha busca por propostas de sucessores alternativos do IPv4, encontrei uma listinha de RFCs relevantes na Wikipédia. Uma delas, a descrição do TP/IX, de 1993, contém a seguinte pérola:
2.1 Is 64 Bits Enough?
Consider: (thought experiment) 32 bits presently numbers "all" of the computers in the world, and another 32 bits could be used to number all of the bytes of on-line storage on each computer. (Most have a lot less than 4 gigabytes on-line, the ones that have more could be notionally assigned more than one address.)
So: 64 bits is enough to number every byte of online storage in existence today, in a hierarchical structured numbering plan.
Far more than one address, camarada.
O TP/IX não é muito diferente do IPv4, sendo as principais diferenças os tamanhos dos endereços e de alguns outros campos. Em contraste com ele, temos a Pip Near-term Architecture. O Pip é uma daquelas coisas que cheiram a Common Lisp: overengineered, faz absolutamente tudo o que você já concebeu e tudo o que você não concebeu, e levanta suspeitas quanto a performance. Em resumo, it's The Right Thing. (Na prática, a performance do Pip provavelmente seria equiparável à do IP. (O paralelo com o Common Lisp é forte.)) Há muitas idéias interessantes no Pip, e vale a pena dar uma lida na RFC. O Pip usa um ID de tamanho fixo para identificar uma máquina, mas usa endereços hierárquicos de tamanho variável para identificar as redes. A RFC prevê o caso de o nível mais alto da hierarquia se esgotar, e sugere que não haveria grandes dificuldades em adicionar um novo nível acima do nível mais alto caso isso ocorresse. Segundo a RFC, algumas das idéias do Pip foram incorporadas ao SIPP (a.k.a. IPv6), mas não sei se essa informação reflete a encarnação atual do IPv6.
E vejam só o que eu descobri: na busca por propostas antigas de sucessores do IPv4, caí nesta página não sei mais como, e vejam só o que temos:
15 March 1992: A Revision of IP Address Classifications
Frank Solenski and Frank Kastenholz proposed C# (C-sharp) IP addresses. This Internet-Draft was available at the Big-Internet list.
¿Qué cosa, no?
Copyright © 2010-2024 Vítor De Araújo
O conteúdo deste blog, a menos que de outra forma especificado, pode ser utilizado segundo os termos da licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.
Powered by Blognir.