O mundo em que o IPv6 era um ótimo projeto (2017)
(apenwarr.ca)- Nas redes iniciais, centradas em conexões ponto a ponto, quase não era preciso um sistema de endereçamento, mas a disseminação das redes em barramento para reduzir custos acumulou complexidades como endereços MAC, bridging e ARP
- Com a combinação de Ethernet e IP, passaram a ser necessários endereçamento por MAC e broadcasts de ARP para encaminhar ao próximo salto, e esse peso aumentou muito em grandes redes interconectadas e no wifi
- A concepção do IPv6 refletia a expectativa de um mundo mais simples, no qual se abandonariam o barramento físico e a internetwork de camada 2, eliminando até broadcast, ARP, DHCP e endereços MAC
- Porém, nos ambientes reais de implantação, IPv4 e o framing legado continuaram presentes, preservando também heranças como neighbor discovery, DHCP, NAT e bridging de camada 2
- Para manter conexões durante deslocamento, continuou-se usando bridging de camada 2 e tunelamento centralizado em vez de roteamento da Internet, e alternativas como QUIC são citadas como vias de contorno para roaming
A rede em barramento foi o começo da ruína de tudo
- Nos primórdios da comutação de circuitos telefônicos e dos links dedicados, existiam apenas conexões ponto a ponto, então não havia necessidade de um sistema de endereçamento; os bits inseridos de um lado simplesmente saíam do outro após algum tempo
- Mesmo após a introdução de TDM e da comutação por circuitos virtuais, para o usuário continuava sendo, na prática, uma entrada de um lado ligada à saída do outro, então ainda não havia necessidade de endereços
- Quando computadores com várias interfaces passaram a encaminhar bits entre linhas, surgiram endereços IP, sub-redes e roteamento, mas em links ponto a ponto ainda não havia necessidade de endereços MAC
- Para reduzir o custo de conectar um site local, surgiram as redes em barramento, que conectavam vários dispositivos ao mesmo cabo; separadamente da família Internet, cada uma criou sua própria camada 2
- A LAN inicial arcnet exigia configurar manualmente endereços de camada 2 de 8 bits com jumpers ou chaves DIP; endereços duplicados causavam falhas graves, mas como a rede era pequena, o incômodo era limitado
- A Ethernet resolveu o problema de duplicação com endereços MAC de 48 bits, atribuindo na fabricação endereços praticamente únicos
- Tecnologias de LAN como IPX e Netware funcionavam bem dentro de uma única rede em barramento sem exigir configuração de endereços, sendo descritas como uma época bonita e confiável
- Grandes redes corporativas e universitárias precisavam interligar vários barramentos por causa do gargalo de um único barramento de 10 Mbps, mas, em vez de IP, ainda imaturo na época, escolheram bridging e switching baseados em endereços Ethernet como caminho de expansão
- Como os endereços Ethernet eram atribuídos sequencialmente na fábrica e não tinham hierarquia, as tabelas de bridging não podiam ser agregadas com eficiência como as tabelas modernas de roteamento IP por sub-rede
- Para fazer bridging de forma eficiente, era preciso lembrar em qual barramento cada endereço MAC estava
- Para evitar configurar isso manualmente, tornou-se necessário aprendizado automático e interações complexas
- Redes complexas de bridges passaram a usar mecanismos como spanning tree, acompanhados de inundação por broadcast, rotas não ótimas e baixa capacidade de depuração
- Bridges intermediárias não tinham conceito de endereço na Ethernet comum, então não havia como criar ferramentas como traceroute; na prática, o bridging era uma estrutura quase impossível de depurar
- Ainda assim, o bridging era extremamente rápido, quase na velocidade de linha da Ethernet, graças à otimização em hardware, e isso era uma grande vantagem na época
A Internet rodando em cima de um barramento
- Partindo de uma estrutura que conectava computadores individuais por links ponto a ponto de longa distância, surgiu gradualmente a demanda por conectar LANs inteiras, o que exigiu conexões de longa distância entre LANs
- O bridging simples a longa distância não funcionava por problemas de controle de congestionamento, e o bridging Ethernet só funcionava sob a premissa de que todos os links tinham velocidades parecidas ou quase não havia congestionamento
- Ligar por bridging uma Ethernet de 10 Mbps a um link ponto a ponto de 0,128 Mbps era inviável, e a descoberta de caminhos baseada em flooding era excessivamente desperdiçadora em links lentos
- O roteamento não ótimo, tolerável em ambiente local, tornava-se fatal em links longos, lentos e caros, sem escalabilidade
- Esse conjunto de problemas já era justamente o domínio com que a Internet lidava, e conectar barramentos LAN com tecnologia da Internet poderia ter produzido uma estrutura muito melhor
- Por isso, foram projetados formatos de frame para transportar pacotes da Internet sobre LANs como Ethernet e arcnet, e foi aí que os problemas começaram
- Se havia vários roteadores IP dentro de um segmento Ethernet, era preciso distinguir qual roteador receberia e encaminharia o pacote; apenas o IP de destino final não expressava essa escolha
- Assim, tornou-se necessário deixar o destino final no cabeçalho IP e indicar o roteador do próximo salto pelo endereço MAC no frame Ethernet
- A informação que a pessoa realmente quer expressar é
enviar para o IP de destino 10.1.1.1 via o MAC do roteador 11:22:33:44:55:66, mas o sistema operacional passou a tratar isso como algo do tipovia o IP do roteador 192.168.1.1 - Para essa abstração, o sistema operacional primeiro precisava descobrir o endereço Ethernet do IP do roteador, e como etapa intermediária foi adicionado o ARP
- O ARP encontra o dono de um IP específico enviando um broadcast para toda a Ethernet local; se houver bridges, como é um broadcast Ethernet, ele precisa ser encaminhado por todas as interfaces
- Em Ethernets grandes e interconectadas, o excesso de broadcasts virou um dos maiores pesadelos, especialmente no wifi
- Depois disso, bridges e switches começaram a inserir hacks especiais para reduzir o alcance do ARP, e alguns dispositivos, especialmente pontos de acesso wifi, chegaram até a gerar respostas ARP falsas, mas tudo isso era basicamente gambiarra técnica
Morte por legado
- Com o tempo, os protocolos não-IP sobre Ethernet quase desapareceram, e a rede se consolidou como uma estrutura composta por uma camada 2 em barramento sobre o meio físico, bridges ligando esses barramentos e roteadores de camada 3 acima disso
- À medida que o cansaço com a configuração manual de IP aumentou, surgiu a demanda por configuração automática, mas os dispositivos já saíam de fábrica com endereços Ethernet e os 32 bits do IPv4 eram insuficientes para atribuições permanentes e únicas na fabricação
- Atribuir endereços IP de forma simplesmente sequencial seria voltar a uma estrutura não hierárquica como a da Ethernet, então isso não era uma boa solução
- Por isso surgiram bootp e DHCP, que se tornaram protocolos que também exigiam tratamento especial, como o ARP
- Como o DHCP precisa ser enviado primeiro por um nó que ainda não tem endereço IP, ele precisa preencher cabeçalhos IP praticamente sem sentido, porém em um formato definido por RFC, e o servidor DHCP precisa preenchê-los diretamente por raw socket, em vez de usar a camada IP do kernel
- Como bootp e DHCP acabam precisando conhecer o endereço Ethernet para atribuir um endereço IP, eles desempenham um papel próximo ao ARP invertido
- Menciona-se que o RARP fazia a mesma coisa de forma mais simples, mas quase não é tratado aqui
- Como resultado, Ethernet e IP foram se entrelaçando cada vez mais, a ponto de hoje serem quase inseparáveis
- As tabelas de roteamento IP fingem especificar roteadores por endereço IP, mas na prática estão especificando indiretamente endereços MAC; o ARP atravessa bridges, e o DHCP parece pacote IP, mas estruturalmente está mais próximo de um protocolo Ethernet
- Ao mesmo tempo, bridging e roteamento ficaram mais complexos, e o bridging ficou em grande parte no domínio do IEEE e do hardware, enquanto o roteamento ficou no domínio do IETF e do software, tratando um ao outro como se não existissem
- Operadores de rede escolhiam entre bridging e roteamento conforme exigências de desempenho e o grau de aversão a configurar servidores DHCP, usando o máximo possível de bridging e recorrendo ao roteamento apenas quando necessário
- A complexidade do bridging acabou levando a elevar as decisões de camada 2 para camadas superiores e gerenciá-las centralmente por um protocolo sobre IP, resultando em SDN
- O SDN era melhor do que deixar switches e bridges agirem cada um por conta própria, mas aponta-se que há algo fundamentalmente irônico nisso, já que o próprio IP, ao lidar em software com uma rede que cresceu demais, já era uma rede definida por software
- No início, o IPv4 era difícil de acelerar em hardware e, na prática, essa aceleração nunca foi suficiente; como a configuração de DHCP também era muito trabalhosa, os operadores aprenderam a fazer bridging em domínios cada vez maiores
- Hoje, grandes datacenters são descritos como funcionando na prática como uma enorme rede virtual em barramento baseada em SDN, frequentemente sem realmente rotear os pacotes
Agora esqueça por um momento a história anterior
- Quando o IETF concebia o IPv6 no começo dos anos 1990, muita confusão já estava em andamento, mas o projeto seguia sob a suposição de que ainda dava para evitar a catástrofe que se aproximava
- Nesse processo, uma mudança central era que o uso de redes físicas em barramento já havia praticamente deixado de existir
- A Ethernet já não era mais um barramento real, apenas fingia ser; com o aumento da velocidade, tornou-se impossível manter CSMA/CD, e ela voltou a uma topologia em estrela
- Tornou-se comum puxar cabos individuais de cada estação até um switch central, e paredes, tetos e pisos passaram a ficar cheios de grandes e caros feixes de cabos Ethernet
- Até o wifi, que parece o barramento definitivo por ser um meio sem fio compartilhado, é descrito como funcionando quase sempre em infrastructure mode, imitando uma grande topologia em estrela
- Mesmo duas estações wifi conectadas ao mesmo ponto de acesso não se comunicam diretamente; se uma envia ao MAC da outra, ela manda o pacote ao ponto de acesso, que então o retransmite
- Quando o nó X envia para o nó Z na Internet, passando pelo roteador IP Y e pelo ponto de acesso wifi A, Z é o destino IP, Y é o destino Ethernet e A é o verdadeiro par da transmissão sem fio, criando uma sobreposição complexa de camadas de endereçamento
- Para isso, o 802.11 fornece o modo de 3 endereços, que carrega ao mesmo tempo o destino Ethernet real e o destino Ethernet intermediário
- Há ainda bits
to-APefrom-APpara indicar as direções estação→AP e AP→estação, e quando ambos são verdadeiros pode-se representar também operação de repetidor entre APs - Se A for um repeater e precisar reenviar para a estação-base B, os participantes reais da transmissão aérea e a origem/destino Ethernet passam todos a ser diferentes, exigindo o modo de 4 endereços
- O 802.11s mesh chega até ao modo de 6 endereços, e o texto diz que, a essa altura, já desistiu de tentar entender
O mundo em que o IPv6 era um bom projeto
- O IETF que pensava o IPv6 olhava para a confusão já existente e para a confusão ainda maior que viria, e imaginava um novo mundo sem o legado existente
- As premissas desse mundo eram: eliminação das redes físicas em barramento, eliminação da internetwork de camada 2, eliminação de broadcasts, eliminação de endereços MAC, eliminação de ARP e DHCP, um cabeçalho IP simples e acelerável em hardware, fim da escassez de endereços e fim da configuração manual de IP fora do core
- Se a camada 2 fosse sempre ponto a ponto, não haveria nem para quem enviar broadcast, então ele poderia ser substituído por multicast; e como o par de envio e recepção seria óbvio, endereços MAC também seriam desnecessários
- Se os endereços MAC desaparecessem, também desapareceria a necessidade de mapear entre IP e MAC, então ARP e DHCP poderiam sumir; além disso, haveria espaço de endereçamento suficiente para voltar a usar roteamento com sub-redes grandes
- Nesse mundo, imagina-se que repetidores wifi, pontos de acesso wifi, switches Ethernet e até SDN teriam funcionado todos como roteadores IPv6
- Então desapareceriam ARP storm, bridges com IGMP snooping e loops de bridging, e todos os problemas de roteamento poderiam ser rastreados com traceroute
- Seria possível remover 12 bytes de MAC de origem e destino de cada pacote Ethernet e 18 bytes de informação de endereço de cada pacote wifi; assim, embora o IPv6 use endereços 24 bytes maiores que o IPv4, ao considerar a remoção do cabeçalho Ethernet, o overhead adicional real seria de apenas 12 bytes
- O texto diz que essa expectativa de um dia eliminar os próprios endereços Ethernet ajudou a justificar a escolha por um comprimento de endereço IPv6 exageradamente grande
- Porém, esse belo projeto não se concretizou no mundo real
Réquiem por um sonho
- A frase de um colega de trabalho, “camadas só são adicionadas, nunca removidas”, é apresentada como a conclusão geral
- As vantagens do IPv6 só fariam sentido se fosse possível abandonar o legado existente e recomeçar, mas na prática isso foi quase impossível
- Mesmo que a adoção do IPv6 chegasse a 99%, enquanto o IPv4 não desaparecer completamente, endereços Ethernet e endereços wifi também não desaparecerão; e enquanto os padrões de framing IEEE 802.3 e 802.11 forem mantidos, essa economia de bytes também não se realizará
- Por isso, o IPv6 acabou precisando de neighbor discovery, ainda mais complexo que o ARP, e mesmo com o desaparecimento da rede em barramento continua sendo necessário simular algo parecido com broadcast para o funcionamento no estilo ARP
- Em casa, ainda é preciso manter um servidor DHCP local para fazer funcionar uma lâmpada IPv4 antiga, e se essa lâmpada precisar alcançar a Internet, o NAT também continua necessário
- Pior ainda, avalia-se que a equipe do IPv6 deixou o problema de mobile IP sem solução, e como resultado o terrível bridging de camada 2 continuou sendo necessário
- Entende-se que o plano na época era implantar primeiro o IPv6 em alguns anos e, depois que IPv4 e endereços MAC desaparecessem, resolver o mobile IP com mais facilidade
- Naquele momento, julgava-se que quase não existia caso de uso para computadores em movimento, e só se conseguia imaginar algo meio estranho como continuar um ftp enquanto se trocava de uma porta Ethernet para outra
Mobile IP como aplicativo matador
- Depois, a história transformou em rotina o caso de uso de computadores carregados no bolso, isto é, telefones, movendo-se entre vários pontos de acesso sem fio
- No LTE, essa mobilidade funciona na maior parte do tempo e, no wifi, às vezes funciona; o segredo, porém, não está no roteamento da Internet, e sim no bridging de camada 2
- O roteamento da Internet não lida com mobilidade de forma alguma: se um dispositivo muda de rede IP e seu endereço IP muda, todas as conexões abertas se quebram
- O wifi corporativo faz bridging da LAN inteira em camada 2 para que um servidor DHCP central forneça o mesmo endereço IP independentemente do ponto de acesso ao qual o dispositivo se conecta, mantendo a conexão com apenas alguns segundos de caos enquanto a bridge se reconfigura
- Redes wifi domésticas com vários extenders ou repeaters usam o mesmo método
- Já ao caminhar pela rua e atravessar redes wifi diferentes, como os wifis públicos de lojas, o dispositivo recebe um novo endereço IP a cada vez e todas as conexões caem
- O LTE vai mais longe e mantém o mesmo endereço IP mesmo quando se atravessam várias milhas entre estações-base; menciona-se que redes móveis normalmente usam endereços IPv6
- O método consiste em tunelar o tráfego até um ponto central e então fazer bridging, junto com muitos firewalls, como se fosse uma única LAN virtual gigantesca de camada 2; o preço é uma complexidade enorme e uma latência adicional constrangedora
- O texto diz que as operadoras gostariam de corrigir isso, mas que é quase impossível
Como fazer o mobile IP realmente funcionar 1
- A explicação para o fracasso do mobile IP leva à conclusão de que a famosa definição de 4-tuple usada para identificar sessões está errada
- Sessões TCP e UDP são identificadas por
(source ip, source port, destination ip, destination port), e essa estrutura cruza as camadas 3 e 4, ficando vulnerável a mudanças de endereço IP - Afirma-se que, se a identificação de sessão dependesse apenas de dados da camada 4, o mobile IP funcionaria perfeitamente
- Como exemplo, quando X:1111 se comunica com Y:80 e X muda de endereço para Q, o pacote vira
(Q,1111,Y,80), e Y não consegue reconhecê-lo como pertencente à sessão anterior, descartando-o; além disso, os pacotes de resposta de Y para(Y,80,X,1111)já não chegam mais a X - Como alternativa, propõe-se ampliar os números de porta, em vez dos atuais 16 bits, para algo como valores de hash únicos de 128 ou 256 bits, identificando sockets por tags independentes do endereço IP
- Nesse caso, os pacotes continuariam contendo os endereços
(X,Y)na camada 3 para roteamento, mas o kernel, ao recebê-los, usaria apenas o uuid para identificar o socket, sem usar a informação da camada 3 - A porta de destino 80 só seria necessária para distinguir o serviço desejado ao iniciar uma nova sessão e depois poderia ser ignorada ou omitida
- O kernel de Y armazenaria em cache que pacotes da sessão
(uuid)vieram recentemente de X e, quando X se movesse para Q e enviasse com a mesma tag(uuid,80), poderia associar isso à mesma sessão e atualizar o destino de resposta de X para Q - Assim a conexão seria mantida, mas o texto acrescenta que seria preciso cuidado extra para evitar sequestro de conexão por falsificação
- Porém, UDP e TCP não funcionam assim, e mudá-los agora é avaliado como um tipo de projeto que parecia tão fácil quanto trocar IPv4 por IPv6, mas que décadas depois continua menos da metade concluído
QUIC e uma possibilidade de desvio
- Pelo lado positivo, sugere-se uma solução indireta por meio de mais uma violação de camadas
- Se abandonarmos o velho TCP e usarmos QUIC sobre UDP, torna-se possível deixar de usar o próprio 4-tuple do UDP como identificador de conexão
- Se a porta UDP for uma porta especial de uma camada de mobilidade, será possível desempacotar seu conteúdo e interpretá-lo como um pacote interno com a tag uuid apropriada, associando-o à sessão e ao socket corretos
- Diz-se que o protocolo experimental QUIC já possui, ao menos em teoria, um formato de pacote adequado para isso
- Como a criptografia e a autenticação stateless usadas pelo QUIC já exigem identificadores ou chaves de sessão únicas, surge a expectativa de que suporte transparente a roaming possa ser obtido com relativamente pouco trabalho
- Se isso acontecer, bastaria então remover da Internet todo o restante de UDP e TCP, e desta vez realmente deixaria de ser necessário o bridging de camada 2, além de se poder eliminar broadcast, endereços MAC, SDN e DHCP
- O texto termina com a frase recuperar a elegância da Internet
Revisões complementares
-
Revisão de 2017-08-16
- A ideia anterior relacionada a mobile IP não se limita ao IPv6
- Foi corrigido que ela pode funcionar também em ambientes com IPv4 e NAT, e até em roaming atravessando vários NATs
-
Revisão de 2017-08-15
- Como forma de evitar sequestro de conexão, apresenta-se como exemplo mais simples uma troca semelhante a SYN-ACK-SYNACK no início do TCP
- Se Y confiar imediatamente no primeiro pacote vindo do novo host Q, fica fácil para um atacante em qualquer lugar da Internet sequestrar a conexão X→Y
- Se Y enviar um cookie e Q o receber, processar e devolver a Y, pelo menos o ataque deixa de ser viável para um agressor externo simples e passa a exigir algo no nível de homem-no-meio
- No caso de protocolos criptografados como QUIC, esse handshake também pode ser protegido com a chave de sessão
-
Revisão de 2017-10-24
- Além do QUIC, existem outros candidatos a protocolo substituto do TCP com suporte a roaming, e MinimaLT é citado como exemplo
- Diz-se que o MinimaLT foi o primeiro protocolo que resolveu o problema de roaming de forma elegante, e sugere-se que soluções futuras provavelmente imitarão essa estrutura
-
Revisão de 2020-07-09
- Há apenas a menção de que pensamentos adicionais sobre migração e interoperabilidade entre IPv4/IPv6 foram publicados em outro texto, sem explicações adicionais no corpo do artigo
1 comentários
Comentários no Hacker News
Na minha visão, o IPv6 talvez não seja o auge absoluto de um design de protocolo perfeito, mas as alternativas melhores que as pessoas propõem acabam convergindo para algo parecido com o IPv6. Se ninguém consegue criar algo consistentemente melhor do que isso, então no fim o IPv6 é um design bem bom
Reunindo discussões antigas do Hacker News, dá para ver que esse assunto continua se repetindo a cada poucos anos, como no tópico de 2017, tópico de 2019, tópico de 2020 e tópico de 2023
Não gosto de como este texto vê o ARP de forma negativa demais. Graças ao ARP, é possível fazer rede IP dentro de uma LAN sem roteador, e o gateway padrão também pode ser tratado como um caso especial da mesma comunicação IP comum em LAN. Dito isso, a explicação da história de redes em si é realmente excelente, e ainda estou lendo a parte sobre IPv6
Fico um pouco confuso sobre o que exatamente este texto quer dizer. Está dizendo que meus equipamentos de rede geram por conta própria endereços IPv6 baseados em MAC address, e que isso é a essência do IPv6 stateless? Pelo que sei, o IPv6 também surgiu para resolver o esgotamento do IPv4 e os problemas de NAT. Mas meu Xbox diz que a rede é ruim quando não há IPv6, e isso também me parece uma visão bastante centrada na América do Norte
Cada vez mais sinto que ter mantido SLAAC e DHCPv6 ao mesmo tempo foi um grande erro no IPv6. O SLAAC em si é excelente, mas dois mecanismos de configuração deixam tudo confuso demais. O fato de o Android não suportar DHCPv6 aumenta ainda mais a confusão. Meu palpite é que o SLAAC é produto de uma época em que computadores eram caros e servidores DHCP eram equipamentos separados. Mas hoje os computadores são baratos e a maioria dos roteadores consegue rodar DHCP, então a situação é outra. Se o DHCPv6 tivesse seguido por um caminho de distribuir endereços por padrão com base em MAC, acho que a configuração teria ficado mais simples, e a autoconfiguração em link-local provavelmente continuaria existindo
Achei este texto muito interessante, mas há um ponto que não entendi bem. O autor diz que agora nem no Wi‑Fi se usa mais CSMA/CD, então queria entender como isso realmente funciona na prática. O autor explica que até duas estações Wi‑Fi conectadas ao mesmo access point não se comunicam diretamente entre si. Nesse caso, em algum momento cada estação precisa distinguir se o sinal que está ouvindo é para ela, se é outra estação enviando algo para o AP, ou se é o AP enviando algo para outra estação. Se é assim, fico me perguntando se algum mecanismo parecido, só com outro nome, ainda não continua sendo necessário
Antigamente o IPv6 parecia o próximo passo inevitável, mas vendo como ele perdeu força agora, fico pensando se o problema que ele queria resolver não era tão importante assim desde o início. Do ponto de vista do usuário real, de algum jeito sempre pareceu haver IPv4 suficiente para manter a internet funcionando, então acabo me perguntando se o IPv6 era mesmo tão necessário. Queria saber se essa conclusão está errada