Resumo

  • O prefixo site-local IPv6 FEC0::/10 oferecia endereços internos sem um prefixo global, mas o endereço não identificava a qual site pertencia.
  • A RFC 4193 trocou essa dependência da fronteira do site por prefixos gerados localmente com alta probabilidade de serem únicos, deixando o roteamento para cada rede.

Análise

A outra metade do endereço ficava no host

Um aplicativo guardava FEC0::1234:5678:9ABC e tentava se conectar. Num host com várias conexões ou que mudava de rede, a sequência hexadecimal podia não bastar: era preciso indicar o site com um identificador de escopo, como %1. Em outra instância do host, o mesmo site podia aparecer como %2. O endereço parecia portátil; a parte que faltava dependia do estado local da máquina.

Esse era o acordo incômodo por trás dos endereços unicast site-local do IPv6. Publicada em abril de 2003, a RFC 3513 definiu FEC0::/10 para uso dentro de um site sem prefixo global. Depois vinham um ID de sub-rede de 54 bits e um ID de interface de 64 bits. Roteadores não deveriam encaminhar pacotes com esses endereços para fora do site. Uma rede podia usar IPv6 internamente sem antes obter um bloco roteável no mundo todo.

O endereço não identificava o site que o tornava local. FEC0::1 podia existir ao mesmo tempo em dois sites. A RFC 3879, de setembro de 2004, descreve o resultado: aplicativos tinham de administrar outro identificador; um endereço literal não podia ser guardado como destino independente do host nem aprendido diretamente pelo DNS; e programas que repassavam endereços IP podiam levar a ambiguidade para além da fronteira local.

“Site” precisava resolver fronteiras demais. Uma rede corporativa, um campus, uma localização geográfica, um domínio de roteamento, uma zona de firewall e um limite administrativo nem sempre coincidem. A RFC 3879 lista limites de segurança, alcance, roteamento, qualidade de serviço, administração e financiamento. Uma DMZ podia estar dentro para uma finalidade e fora para outra. O pacote tinha um endereço; a organização tinha vários mapas.

Os roteadores herdaram a mesma disputa. Se o mesmo destino site-local significava coisas diferentes conforme a interface pela qual o pacote chegava, um roteador conectado a vários sites precisava de rotas específicas para cada um e de tratamento especial nas tabelas de encaminhamento. Túneis e tabelas virtualizadas podiam carregar o trabalho, mas não transformavam “site” numa unidade universal.

A vantagem era real: endereços internos sem prefixo global e uma fronteira que os roteadores podiam filtrar. Em 2003, o grupo de trabalho de IPv6 avançou na direção de uma substituição. A RFC 3879 registra um acordo em março e sua confirmação em julho, mas ressalva que o consenso esteve longe de ser unânime. O documento de setembro de 2004 aposentou FEC0::/10, porém permitiu que implementações e redes existentes continuassem usando o prefixo até a padronização de um substituto. Uma futura ação de padrões da IETF seria necessária para destiná-lo a outro uso.

A RFC 4193 trouxe a substituição em outubro de 2005. Endereços IPv6 locais únicos usam FC00::/7; nos prefixos atribuídos localmente, um Global ID de 40 bits é gerado pseudoaleatoriamente, seguido por um ID de sub-rede de 16 bits e um ID de interface de 64. “Global” descreve a unicidade pretendida para o prefixo, não acesso pela Internet. A RFC fala em alta probabilidade de unicidade, não em certeza. Esses endereços são para comunicação local, podem ser roteados entre um conjunto limitado de sites e não devem circular nas rotas globais da Internet.

Essa diferença aparece quando redes se juntam. É improvável que prefixos ULA gerados separadamente colidam; uma fusão ou interconexão privada costuma poder evitar renumerar as interfaces. Ainda assim, é preciso configurar rotas explícitas entre os sites. O endereço deixa de codificar uma definição universal de “site”; cada rede decide por onde suas rotas e seus filtros o deixam passar.

Em fevereiro de 2006, a RFC 4291 incorporou a aposentadoria à arquitetura de endereçamento IPv6: novas implementações não devem manter o comportamento especial de FEC0::/10. A sequência de RFCs explica a mudança de projeto, mas não conta quantos sistemas ainda usam o prefixo. Para saber a prevalência hoje, seriam necessárias medições atuais de hosts, roteadores ou tráfego.

Fontes