O mundo em que o IPv6 era um excelente projeto (2017)
(apenwarr.ca)- Nas redes iniciais centradas em conexões ponto a ponto, quase não havia necessidade de um sistema de endereçamento, mas a difusã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, passou a ser necessário usar endereçamento MAC e broadcast ARP para encaminhar ao próximo salto, e esse custo aumentou muito em grandes redes interconectadas e no wifi
- A concepção do IPv6 refletia a expectativa de um mundo mais simples, abandonando o barramento físico e o internetwork de camada 2 e eliminando até broadcast, ARP, DHCP e endereços MAC
- Porém, nos ambientes reais de implantação, IPv4 e o framing legado continuaram presentes, mantendo junto heranças como neighbor discovery, DHCP, NAT e bridging de camada 2
- Para manter conexões durante deslocamento, continuam sendo usados bridging de camada 2 e tunelamento centralizado em vez de roteamento da Internet, e alternativas como QUIC são citadas como um caminho indireto para roaming
O momento em que as redes em barramento estragaram tudo
- Nos ambientes iniciais de comutação de circuitos da telefonia e de linhas dedicadas, existiam apenas conexões ponto a ponto, então não era necessário um sistema de endereçamento; os bits inseridos de um lado 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 ainda era basicamente um fluxo em que a entrada de um lado se ligava à saída do outro, e nessa etapa ainda não havia necessidade de endereços
- Quando computadores com várias interfaces passaram a encaminhar bits entre enlaces, surgiram endereços IP, sub-redes e roteamento, mas em enlaces ponto a ponto ainda não havia necessidade de endereços MAC
- Para reduzir o custo de conectar dispositivos em um site local, surgiram as redes em barramento, que ligavam vários dispositivos ao mesmo cabo, e apareceram esquemas próprios de camada 2 separados da família Internet
- A LAN inicial arcnet exigia configurar manualmente endereços de camada 2 de 8 bits com jumpers ou chaves DIP; duplicações causavam falhas graves, mas como a rede era pequena esse inconveniente era limitado
- A Ethernet resolveu o problema de duplicação ao introduzir endereços MAC de 48 bits, atribuídos na fabricação de forma quase única
- Tecnologias de LAN como IPX e Netware funcionavam bem dentro de uma única rede em barramento sem configuração de endereços, descritas como uma época em que tudo era bonito e confiável
- Grandes redes corporativas e universitárias precisaram interligar vários barramentos por causa do gargalo de um único barramento de 10 Mbps e, 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, sem hierarquia, as tabelas de bridging não podiam agregá-los com a eficiência de 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 configuração manual, passaram a ser necessários aprendizado automático e interações complexas
- Redes complexas de bridges passaram a depender de mecanismos como spanning tree, trazendo flooding de broadcast, rotas não ideais e baixa capacidade de depuração
- Nos bridges intermediários, a Ethernet comum não tinha um conceito de endereço útil para criar ferramentas como traceroute, e o bridging acabou sendo uma estrutura praticamente impossível de depurar
- Ainda assim, o bridging era extremamente rápido, perto da velocidade de fio da Ethernet, graças à otimização em hardware, e isso era uma grande vantagem na época
A Internet rodando sobre um barramento
- A estrutura de conectar computadores individuais por enlaces ponto a ponto de longa distância evoluiu gradualmente para a necessidade de conectar LANs inteiras a longa distância
- Um bridge simples de longa distância não funcionava por causa de problemas de controle de congestionamento, e o bridging Ethernet só funcionava quando todos os enlaces tinham velocidades parecidas ou quase não havia congestionamento
- Fazer bridging diretamente entre uma Ethernet de 10 Mbps e um enlace ponto a ponto de 0,128 Mbps era inviável, e a descoberta de caminhos por flooding desperdiçava demais em enlaces lentos
- O roteamento não ideal, tolerável localmente, era fatal em enlaces de longa distância lentos e caros, portanto não escalava
- Esse conjunto de problemas já era justamente o domínio em que a Internet tinha experiência, e conectar barramentos de LAN com tecnologia da Internet poderia produzir uma estrutura muito melhor
- Por isso, foram definidos formatos de quadro para transportar pacotes da Internet sobre LANs como Ethernet e arcnet, e foi aí que os problemas começaram
- Se vários roteadores IP estivessem dentro de um segmento Ethernet, era preciso distinguir qual roteador receberia e encaminharia o pacote, e só o IP de destino final não bastava para expressar essa escolha
- Assim, o destino final ficava no cabeçalho IP, enquanto o próximo salto real era especificado pelo endereço MAC no quadro Ethernet
- A informação real que uma pessoa quer expressar é
enviar o IP de destino 10.1.1.1 para o MAC do roteador 11:22:33:44:55:66, mas o sistema operacional acaba tratando isso como algo do tipovia 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 para isso foi acrescentado o ARP
- O ARP encontra o dono de um determinado IP enviando um broadcast para toda a Ethernet local; se houver bridges, como isso é um broadcast Ethernet, ele precisa ser repassado por todas as interfaces
- Em grandes redes Ethernet interconectadas, broadcast excessivo virou um dos maiores pesadelos, especialmente no wifi
- Depois, bridges e switches começaram a inserir hacks especiais para reduzir o alcance do ARP, e alguns dispositivos, especialmente pontos de acesso wifi, chegaram a gerar respostas ARP falsas, mas tudo isso era essencialmente gambiarra técnica
Morte pelo legado
- Com o tempo, os protocolos não IP sobre Ethernet praticamente desapareceram, e a rede se consolidou numa estrutura com uma camada 2 em barramento sobre fios físicos, bridges ligando esses barramentos e roteadores de camada 3 acima disso
- À medida que o cansaço com a configuração manual de IP aumentava, surgiu a demanda por configuração automática, mas os dispositivos já saíam de fábrica com endereços Ethernet e o espaço de 32 bits do IPv4 era insuficiente para atribuições únicas permanentes ainda na fabricação
- Atribuir endereços IP em sequência simples não era uma boa solução, porque isso nos levaria de volta a uma estrutura não hierárquica como a Ethernet
- Então surgiram bootp e DHCP, que também se tornaram protocolos que exigiam tratamento especial, como o ARP
- Como o DHCP precisa ser transmitido primeiro por um nó que ainda não tem endereço IP, ele precisa preencher um cabeçalho IP praticamente sem sentido, porém no formato exigido pela RFC, e o servidor DHCP acaba montando isso diretamente via raw socket em vez de usar a camada IP do kernel
- Como bootp e DHCP precisam conhecer o endereço Ethernet para atribuir um endereço IP, eles acabam fazendo quase o papel inverso do ARP
- O texto menciona que o RARP fazia a mesma coisa de forma mais simples, mas quase não é tratado ali
- No fim, Ethernet e IP ficaram cada vez mais entrelaçados, a ponto de hoje serem quase inseparáveis
- Tabelas de roteamento IP fingem especificar roteadores por endereço IP, mas na prática estão especificando endereços MAC de forma indireta; o ARP atravessa bridges, e o DHCP parece um pacote IP, mas na prática se aproxima mais de um protocolo Ethernet
- Ao mesmo tempo, bridging e roteamento ficaram cada vez mais complexos; o bridging em geral ficou do lado do IEEE e do hardware, e o roteamento do lado do IETF e do software, como se um pudesse ignorar a existência do outro
- Operadores de rede escolhiam entre bridging e roteamento conforme exigências de desempenho e o quanto queriam evitar configurar servidores DHCP; usavam o máximo possível de bridging e roteamento apenas quando necessário
- A complexidade do bridging acabou levando ao SDN, que puxa decisões de camada 2 para camadas superiores e as gerencia centralmente com protocolos sobre IP
- O SDN era melhor do que deixar switches e bridges agirem cada um por conta própria, mas o texto observa uma certa ironia fundamental nisso, porque o próprio IP, usado para controlar uma rede que cresceu demais, já era uma rede definida por software
- O IPv4 era difícil de acelerar em hardware no começo e, na prática, por muito tempo não foi suficientemente acelerado; como configurar DHCP era trabalhoso, operadores aprenderam a fazer bridging de domínios cada vez maiores
- Hoje, grandes datacenters são descritos como imensas redes virtuais em barramento baseadas em SDN, muitas vezes sem realmente rotear pacotes de forma efetiva
Agora esqueça por um momento a história anterior
- Quando o IETF pensava no IPv6 no início dos anos 1990, muita confusão já estava em andamento, mas o projeto seguiu sob a suposição de que ainda seria possível evitar o desastre que vinha pela frente
- Nesse processo, uma mudança central era que o uso de redes físicas em barramento já havia sido praticamente abandonado
- A Ethernet já não era mais um barramento de verdade, apenas fingia ser; com o aumento de velocidade, ficou impossível manter CSMA/CD e ela voltou a uma topologia em estrela
- Tornou-se comum puxar um cabo individual de cada estação até um switch central, enchendo paredes, tetos e pisos com grandes e caros feixes de cabos Ethernet
- Até o wifi, que parece o barramento definitivo por ser um meio sem fio compartilhado, é descrito como algo que na prática quase sempre imita uma enorme topologia em estrela em infrastructure mode
- Mesmo duas estações wifi conectadas ao mesmo ponto de acesso não se comunicam diretamente; enviam pacotes ao ponto de acesso com o MAC do outro nó, e o ponto de acesso os retransmite
- Se o nó X envia para o nó Z na Internet, passando pelo roteador IP Y e pelo ponto de acesso wifi A, então Z é o destino IP, Y é o destino Ethernet e A é o verdadeiro par da transmissão sem fio, o que cria uma sobreposição complicada de camadas de endereços
- Para isso, o 802.11 fornece modo de 3 endereços, que carrega ao mesmo tempo o destino Ethernet real e o destino Ethernet intermediário
- Existem ainda os bits
to-APefrom-AP, que indicam a direção estação→AP e AP→estação, e quando ambos são verdadeiros é possível representar também o funcionamento de repetidor entre APs - Se A é um repetidor e precisa reenviar para uma estação-base B, os reais participantes da transmissão pelo ar e a origem e o destino Ethernet tornam-se todos diferentes, exigindo modo de 4 endereços
- O 802.11s mesh chega até modo de 6 endereços, e o texto comenta que, a essa altura, desistiu de tentar entender
O mundo em que o IPv6 era um bom projeto
- O IETF que refletia sobre o IPv6 viu tanto a confusão já existente quanto a ainda maior que estava por vir, e imaginou um novo mundo livre do legado existente
- Os pressupostos desse mundo eram eliminar redes físicas em barramento, eliminar internetwork de camada 2, eliminar broadcast, eliminar endereços MAC, eliminar ARP e DHCP, ter um cabeçalho IP simples acelerável por hardware, acabar com a falta de endereços e remover a configuração manual de IP fora do núcleo da rede
- Se a camada 2 fosse sempre ponto a ponto, então não existiria nem mesmo um alvo para broadcast, de modo que 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 de grandes sub-redes
- Nesse mundo, repetidores wifi, pontos de acesso wifi, switches Ethernet e até SDN teriam funcionado todos como roteadores IPv6
- Assim, ARP storms, bridges com IGMP snooping e loops de bridging desapareceriam, 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 eliminar o 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 de um comprimento de endereço IPv6 tão excessivamente grande
- Mas esse belo projeto nunca se realizou no mundo real
Réquiem por um sonho
- A conclusão geral vem numa frase de um colega de trabalho: "camadas só são adicionadas, nunca removidas"
- As vantagens do IPv6 só fariam sentido se fosse possível abandonar o legado existente e recomeçar, mas na prática isso quase não era viável
- Mesmo que a adoção do IPv6 chegasse a 99%, enquanto o IPv4 não desaparecesse completamente, os endereços Ethernet e wifi também não desapareceriam; e enquanto os padrões de framing IEEE 802.3 e 802.11 continuassem, essa economia de bytes também não se materializaria
- Por isso, o IPv6 acabou precisando de neighbor discovery, ainda mais complexo que o ARP, e mesmo com o desaparecimento das redes em barramento ainda continuou sendo necessária uma espécie de simulação de broadcast para reproduzir o comportamento tipo ARP
- Em casa, ainda é preciso manter um servidor DHCP local para fazer funcionar uma lâmpada IPv4 antiga, e se essa lâmpada precisa alcançar a Internet, o NAT também continua necessário
- Pior ainda, o texto avalia que a equipe do IPv6 deixou sem resolver o problema de mobile IP, o que acabou mantendo a necessidade de um terrível bridging de camada 2
- O entendimento apresentado é que, na época, o plano era implantar primeiro o IPv6 em poucos anos e depois, quando IPv4 e endereços MAC tivessem desaparecido, resolver mobile IP com mais facilidade
- Naquele momento, quase não se imaginava um caso de uso real para computadores em movimento; só dava para fantasiar cenários meio estranhos como continuar um ftp enquanto se trocava de uma porta Ethernet para outra
Mobile IP como aplicativo matador
- Depois, na história real, tornou-se cotidiano usar computadores carregados no bolso — isto é, telefones — movendo-se entre vários pontos de acesso sem fio
- No LTE, esse deslocamento geralmente funciona; no wifi, às vezes funciona; e o segredo, segundo o texto, não está no roteamento da Internet, mas no bridging de camada 2
- O roteamento da Internet não lida com mobilidade de forma alguma, e se você se move numa rede IP e seu endereço IP muda, todas as conexões abertas se quebram
- O wifi corporativo faz bridging de toda a LAN em camada 2 para que um servidor DHCP central atribua o mesmo endereço IP independentemente do ponto de acesso ao qual você se conecte, preservando a conexão ao custo de alguns segundos de confusão enquanto os bridges se reconfiguram
- O mesmo método é usado no wifi doméstico com vários extenders ou repetidores
- Em contraste, quando você anda pela rua mudando entre redes wifi diferentes, como wifis públicos de lojas, recebe um novo endereço IP a cada vez, e todas as conexões são derrubadas
- O LTE vai além e mantém o mesmo endereço IP mesmo após se mover por vários quilômetros entre estações-base, e o texto menciona que redes móveis em geral usam endereços IPv6
- O método é tunelar o tráfego até um ponto central e então fazer bridging, junto com muitas firewalls, como se tudo fosse uma única LAN virtual gigantesca de camada 2, ao preço de enorme complexidade e uma latência extra constrangedora
- As operadoras gostariam de corrigir isso, mas o texto diz que é praticamente impossível
Como fazer mobile IP realmente funcionar 1
- A resposta para por que mobile IP não funciona direito leva à conclusão de que a famosa definição do 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 atravessa as camadas 3 e 4, ficando vulnerável a mudanças de endereço IP - O texto argumenta que, se a identificação da sessão dependesse apenas de dados da camada 4, mobile IP funcionaria perfeitamente
- Como exemplo, quando X:1111 se comunica com Y:80 e X muda de endereço para Q, os pacotes passam a ser
(Q,1111,Y,80), então Y não os reconhece como parte da sessão existente e os descarta; e os pacotes de retorno(Y,80,X,1111)também deixam de alcançar X - Como alternativa, propõe-se ampliar o número de porta, em vez dos atuais 16 bits, para algo como 128 ou 256 bits de valor hash único, identificando sockets por uma tag independente do endereço IP
- Nesse caso, os pacotes ainda carregariam informações de endereço
(X,Y)na camada 3 para roteamento, mas o kernel, ao receber, não usaria a camada 3 para identificar o socket, apenas o uuid - A porta de destino 80 só seria necessária para escolher o serviço desejado no início de uma nova sessão; depois disso, poderia ser ignorada ou omitida
- O kernel de Y armazenaria em cache que os pacotes da sessão
(uuid)vieram recentemente de X; quando X se movesse para Q e enviasse pacotes com a mesma tag(uuid,80), eles seriam associados à sessão existente e o destino de resposta seria atualizado de X para Q - Isso manteria a conexão viva, embora o texto acrescente que seria preciso cuidado extra para impedir sequestro de conexão por falsificação de identidade
- Mas UDP e TCP não funcionam assim, e mudar isso agora é descrito como um tipo de projeto que parecia tão simples quanto trocar IPv4 por IPv6, mas que décadas depois ainda estaria menos da metade concluído
QUIC e a possibilidade de contornar o problema
- Em um ponto mais positivo, o texto sugere 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 da conexão
- Se a porta UDP for uma porta especial de uma camada de mobilidade, o conteúdo interno pode ser reinterpretado como pacotes internos com a tag uuid apropriada e então associado à sessão e ao socket corretos
- O protocolo experimental QUIC é descrito como algo que, ao menos em teoria, já possui um formato de pacote adequado a essa estrutura
- Como a criptografia e a autenticação stateless de pacotes usadas pelo QUIC já exigem um identificador ou chave de sessão únicos, haveria esperança de suportar roaming transparente com relativamente pouco trabalho adicional
- Se isso acontecer, bastaria então remover da Internet todo o restante de UDP e TCP e, desta vez, de fato o bridging de camada 2 não seria mais necessário, e também seria possível eliminar broadcast, endereços MAC, SDN e DHCP
- O texto termina com a frase restaurar a elegância da Internet
Correções complementares
-
Correção de 2017-08-16
- A ideia anterior sobre mobile IP não se limita ao IPv6
- Foi corrigido para dizer que ela também pode funcionar em IPv4 com NAT, e até em roaming atravessando múltiplos NATs
-
Correção de 2017-08-15
- Como exemplo mais simples para evitar sequestro de conexão, é proposto um intercâmbio semelhante a SYN-ACK-SYNACK no início do TCP
- Se Y confiar imediatamente no primeiro pacote do novo host Q, um atacante em qualquer lugar da Internet poderia sequestrar facilmente a conexão X→Y
- Se Y enviar um cookie e Q tiver de recebê-lo, processá-lo e devolvê-lo a Y, então pelo menos o atacante precisaria ser um intermediário, e não apenas um invasor externo simples
- No caso de protocolos criptografados como QUIC, esse handshake também pode ser protegido pela chave de sessão
-
Correção de 2017-10-24
- Além do QUIC, há outros candidatos a protocolos substitutos do TCP com suporte a roaming, e MinimaLT é citado como exemplo
- O texto diz ter ouvido que o MinimaLT foi o primeiro protocolo a resolver o problema de roaming de forma elegante, e sugere que futuras soluções podem seguir essa mesma estrutura
-
Correção de 2020-07-09
- Há apenas a menção de que pensamentos adicionais sobre migração e interoperabilidade entre IPv4 e IPv6 foram publicados em outro texto, sem explicações extras no corpo deste 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