Hoje descobri acidentalmente que posso pingar endereços na 172.31.0.0/16sub-rede e obter uma resposta ICMP. Eu tentei alguns aleatórios, sempre obtive respostas. Depois de verificar a tabela de roteamento e uma tentativa traceroute, parece que os pacotes associados estão saindo da minha rede local, ou seja, saindo em direção ao meu ISP. Minha rede local usa um intervalo de IP diferente, parte da 192.168.0.0/16sub-rede e há interfaces relacionadas ao Docker para 172.17.0.0/16e 172.19.0.0/16, mas não para 172.31.0.0/16.
Era meu entendimento que 172.31.0.0/16ainda deveria fazer parte do 172.16.0.0/12espaço de endereço reservado pela IANA.
Eu tentei uma pesquisa na web para ver se o intervalo dessa sub-rede pode ter sido reduzido devido à falta de endereço IP global ou por qualquer outro motivo, mas não consegui encontrar nada para apoiar essa hipótese.
Agora estou me perguntando se estou apenas com falta de sono e negligenciando algo elementar ou se há algo seriamente errado na minha configuração de rede.
Você está correto que 172.31.0.0/16 faz parte do espaço de endereço IP RFC1918. Seu roteador provavelmente está configurado para despejar tráfego em rotas não conectadas para seu gateway padrão, seu ISP. É aí que o trânsito deve parar.
No entanto, parece que seu ISP tornou esse intervalo de endereços roteável. Já vi isso acontecer no passado com outros ISPs (Tele2, por exemplo, usava 1.0.0.0/8 para seu backbone antes de ser atribuído pela IANA).
De qualquer forma, você (e seu ISP) provavelmente deve implementar filtragem bogon e/ou filtragem marciana nas fronteiras de suas redes. Para o consumidor doméstico médio, isso é desculpável, mas um ISP deve saber melhor.
Para evitar esse problema, você pode configurar um filtro de saída básico no firewall do seu roteador (por exemplo,
10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.0.0/16). Outra opção é rotear nula ou rota de buraco negro esses intervalos de endereços. Seu roteador então descartará os pacotes.