Elmord's Magic Valley

Software, lingüística e rock'n'roll. Sometimes in English.

IP do futuro, vinte anos atrás

2012-05-23 01:08 -0300. Tags: comp, network

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?

Comentários / Comments (0)

Deixe um comentário / Leave a comment

Main menu

Posts recentes

Comentários recentes

Tags

comp (124) prog (59) life (45) in-english (33) unix (32) lang (30) random (28) pldesign (27) about (25) mind (23) lisp (22) mundane (21) web (17) ramble (15) img (13) rant (12) fenius (12) hel (12) privacy (10) scheme (9) freedom (8) lash (7) academia (7) bash (7) music (7) copyright (7) esperanto (7) home (6) shell (6) mestrado (6) misc (5) conlang (5) php (4) editor (4) latex (4) book (4) politics (4) worldly (4) etymology (4) security (3) film (3) kbd (3) tour-de-scheme (3) network (3) c (3) android (3) emacs (3) wrong (3) poem (2) cook (2) physics (2) llvm (2) lows (2) comic (2) treta (2) perl (1) wm (1) audio (1) german (1) kindle (1) pointless (1) philosophy (1)

Elsewhere

Quod vide


Copyright © 2010-2019 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.