{"id":34586,"date":"2026-10-02T15:29:46","date_gmt":"2026-10-02T15:29:46","guid":{"rendered":"https:\/\/blog.lacnic.net\/?p=34586"},"modified":"2026-10-02T15:53:08","modified_gmt":"2026-10-02T15:53:08","slug":"hosts-dupla-quase","status":"publish","type":"post","link":"https:\/\/blog.lacnic.net\/pt-br\/hosts-dupla-quase\/","title":{"rendered":"Hosts de pilha dupla quase exclusivos do IPv6"},"content":{"rendered":"\n

Por Alejandro Acosta<\/a><\/p>\n\n\n\n

Hoje vamos falar sobre o Internet Draft chamado: \u201cHosts de pilha dupla quase exclusivos do IPv6\u201d (Nearly IPv6 Only Dual Stack Hosts)<\/p>\n\n\n\n

Introdu\u00e7\u00e3o<\/strong><\/strong><\/h2>\n\n\n\n

Este documento t\u00e9cnico prop\u00f5e um m\u00e9todo para gerenciar dispositivos de pilha dupla (dual stack<\/em>) que n\u00e3o requerem conectividade IPv4, mas continuam gerando tr\u00e1fego de rede ao solicitar endere\u00e7os automaticamente (como cliente DHCPv4).<\/p>\n\n\n\n

A estrat\u00e9gia consiste em designar-lhes uma m\u00e1scara de sub-rede 255.255.255.255 por meio do DHCPv4, o que efetivamente isola o equipamento; isso impede a comunica\u00e7\u00e3o com destinos externos sob esse protocolo. Ao omitir a configura\u00e7\u00e3o de um gateway<\/em> ou roteador, o tr\u00e1fego \u00e9 direcionado para o protocolo IPv6, eliminando a necessidade de suporte para op\u00e7\u00f5es de rede mais modernas e complexas. Essa t\u00e9cnica reduz o ru\u00eddo na rede local e permite a reutiliza\u00e7\u00e3o de faixas de endere\u00e7os privados sem afetar o roteamento global. Al\u00e9m disso, o autor sugere a implementa\u00e7\u00e3o de per\u00edodos de concess\u00e3o de endere\u00e7os mais longos para minimizar a carga nos servidores. Em resumo, apresenta-se uma solu\u00e7\u00e3o pr\u00e1tica para a transi\u00e7\u00e3o para redes s\u00f3 IPv6 usando mecanismos de infraestrutura tradicionais.<\/p>\n\n\n\n

<\/a>O problema que se procura resolver<\/strong><\/h2>\n\n\n\n

O rascunho resolve o problema de como silenciar solicita\u00e7\u00f5es DHCPv4 ruidosas dos dispositivos mais antigos e remover de forma efetiva o acesso ao IPv4 (for\u00e7ando-os a usar o IPv6), usando os mecanismos DHCPv4 tradicionais que esses mesmos dispositivos mais antigos j\u00e1 entendem, sem a necessidade de atualizar seu software.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Especificamente, o documento aborda os seguintes problemas interligados:<\/p>\n\n\n\n

    \n
  1. Tr\u00e1fego de lixo na rede local (broadcasts infinitos):<\/strong> Quando uma rede de pilha dupla deseja migrar para um ambiente s\u00f3 IPv6, o passo l\u00f3gico seria parar de entregar endere\u00e7os IPv4 aos dispositivos. No entanto, se a designa\u00e7\u00e3o do IPv4 for simplesmente desativada, os sistemas operacionais dos hosts continuar\u00e3o enviando solicita\u00e7\u00f5es DHCPv4 de forma peri\u00f3dica, e malsucedida. Lembre-se de que este tr\u00e1fego DHCPv4 \u00e9 geralmente broadcast.<\/li>\n\n\n\n
  2. Incompatibilidade de dispositivos antigos com solu\u00e7\u00f5es modernas:<\/strong> Muitos j\u00e1 conhecem as redes IPv6-Mostly<\/em>, nas quais a Op\u00e7\u00e3o 108<\/strong> do DHCPv4 (IPv6-Only Preferred<\/em>) \u00e9 a chave. E qual \u00e9 o problema? Essa op\u00e7\u00e3o permite que um \u201cdispositivo moderno\u201d informe ao servidor que prefere n\u00e3o receber um IPv4 se houver IPv6 dispon\u00edvel. Em outras palavras, o problema \u00e9 que os dispositivos antigos n\u00e3o reconhecer\u00e3o essa op\u00e7\u00e3o DHCPv4<\/strong> e continuar\u00e3o enviando broadcast<\/em> indefinidamente.<\/li>\n\n\n\n
  3. O \u201cdilema\u201d da designa\u00e7\u00e3o do IPv4:<\/strong> Os administradores de rede s\u00e3o obrigados a continuar oferecendo endere\u00e7amento IPv4, mantendo uma rede IPv6 e servidores DHCPv4 apenas para ‘manter calados’ os clientes mais antigos.<\/li>\n<\/ol>\n\n\n\n

    Solu\u00e7\u00e3o proposta<\/strong><\/h2>\n\n\n\n

    Na minha humilde opini\u00e3o, a solu\u00e7\u00e3o \u00e9 muito criativa.<\/p>\n\n\n\n

    Procura-se atender \u00e0s necessidades do host\/cliente. O cliente quer um endere\u00e7o IPv4 fornecido pelo servidor DHCP. O que o servidor DHCP faz? Tudo bem, vou te dar um. O que o cliente \u201cmatematicamente n\u00e3o sabe\u201d \u00e9 que esse endere\u00e7o IP \u00e9 praticamente in\u00fatil.<\/p>\n\n\n\n

    N\u00e3o vou abordar todas as ideias mencionadas no draft<\/em>, mas sim as duas mais interessantes:<\/p>\n\n\n\n

    A solu\u00e7\u00e3o proposta no rascunho (Internet-Draft<\/em>) para permitir que os hosts<\/em> de pilha dupla (dual-stack<\/em>) operem de maneira quase exclusiva no IPv6 consiste em um m\u00e9todo sutil, por\u00e9m altamente eficaz, baseado na configura\u00e7\u00e3o do DHCPv4 tradicional<\/strong>:<\/p>\n\n\n\n

      \n
    1. Configurar uma m\u00e1scara de sub-rede<\/strong> \/32 (255.255.255.255)<\/strong>: Por meio da op\u00e7\u00e3o 1 do DHCPv4 (Subnet Mask<\/em>), o cliente recebe uma m\u00e1scara de sub-rede de host<\/em> \u00fanico. Ao receber essa m\u00e1scara, o dispositivo conclui que n\u00e3o existe nenhum outro endere\u00e7o IPv4 no seu pr\u00f3prio link f\u00edsico, ou seja, todo o tr\u00e1fego IPv4 para o exterior \u00e9 considerado automaticamente como fora de seu link ou off-link<\/em>.<\/li>\n\n\n\n
    2. Omitir a entrega de roteadores (gateways<\/em>)<\/strong>: O servidor DHCPv4 n\u00e3o fornece nenhum endere\u00e7o de roteador ao cliente (a Op\u00e7\u00e3o de Roteador, op\u00e7\u00e3o valor 3, \u00e9 removida deliberadamente).<\/li>\n<\/ol>\n\n\n\n

      Dessa maneira, o host<\/em> antigo satisfaz sua necessidade de obter um endere\u00e7o IPv4 (silenciando as requisi\u00e7\u00f5es de broadcast<\/em> repetitivas), mas fica isolado da rede IPv4 e \u00e9 for\u00e7ado a se comunicar exclusivamente via IPv6 (adicionalmente devemos somar o tr\u00e1fego broadcast<\/em> do ARP).<\/p>\n\n\n\n

      \"\"<\/figure>\n\n\n\n

      Como o procedimento acima isola um host<\/em> no mundo IPv4?<\/strong><\/h2>\n\n\n\n
        \n
      1. O efeito da m\u00e1scara<\/strong> \/32: Ao configurar a interface do host<\/em> com uma m\u00e1scara 255.255.255.255, o sistema operacional entende que n\u00e3o h\u00e1 nenhum outro endere\u00e7o IPv4 no seu pr\u00f3prio link<\/strong>. Portanto, para o host<\/em>, absolutamente qualquer endere\u00e7o IPv4 externo \u00e9 considerado fora de seu alcance.<\/li>\n\n\n\n
      2. Procura por um roteador inexistente:<\/strong> Ao presumir que todos os destinos IPv4 est\u00e3o em redes externas, o host<\/em> tentar\u00e1 enviar qualquer pacote IPv4 por meio de seu gateway<\/em> ou roteador padr\u00e3o. No entanto, o m\u00e9todo do draft<\/em> consiste em n\u00e3o fornecer nenhum roteador<\/strong> via DHCPv4.<\/li>\n<\/ol>\n\n\n\n
        \"\"<\/figure>\n\n\n\n

        At\u00e9 aqui, o host<\/em> atende \u00e0 sua necessidade de obter um IP via DHCPv4 e, al\u00e9m disso, n\u00e3o gera tr\u00e1fego de broadcast<\/em> repetitivo na rede.<\/p>\n\n\n\n

        <\/a>Quais vantagens este m\u00e9todo oferece em rela\u00e7\u00e3o \u00e0s redes IPv6-Mostly?<\/strong><\/h2>\n\n\n\n

        A principal vantagem deste m\u00e9todo (fornecer uma m\u00e1scara de sub-rede 255.255.255.255<\/strong> e n\u00e3o entregar o gateway<\/em> padr\u00e3o) em rela\u00e7\u00e3o \u00e0 Op\u00e7\u00e3o 108<\/strong> (IPv6-Only Preferred) \u00e9 a compatibilidade com dispositivos e servidores legados (antigos)<\/strong>.<\/p>\n\n\n\n