Devido à eficiência e complexidade do tempo. Basicamente, é a mesma razão pela qual devemos manter as tabelas de roteamento curtas (mas em um nível diferente), pois para cada pacote recebido, o sistema precisa percorrer toda a tabela de roteamento procurando uma correspondência para saber como rotear esse pacote. Isso resulta em tempos de pesquisa médios e piores de O (n) para o comprimento da tabela de roteamento.
Os endereços de interface têm o mesmo problema com implicações semelhantes. A interface pode potencialmente ter que verificar milhares de pacotes por segundo que passam pelo cabo, para determinar quais deles são destinados a esse host. A maneira simples é: para cada pacote que chega, compare seu endereço de destino com cada faixa de endereços atribuída a essa interface. Note que esta é outra tarefa seqüencial que leva O (n) para cada pacote, o que significa: ele custa tempo de processamento, potencialmente muito se você tiver que processar milhares de pacotes por segundo.
E há outro problema: à medida que você adiciona mais e mais endereços ao link local, cada novo endereço aumenta a memória exigida por todos os outros hosts no link, em suas tabelas vizinhas (ARP). Este não é um grande problema (o Proxy ARP faz o mesmo), mas ainda há algum impacto no desempenho de toda a rede local que você deve estar ciente.
Isso faz com que atribuir um grande número de endereços a um único host seja uma idéia não muito boa. Um limite muito conservador como 16 ou 32 é bom o suficiente e também lembra os administradores desses custos.
Se você precisar de um grande número de endereços roteados para uma única máquina, você deve criar uma sub-rede. Escolha todos os endereços consecutivos dentro de uma sub-rede e direcione toda a sub-rede para essa máquina. Então você usa alguma forma de roteamento interno ou alguns truques iptables / route para fazer todo o trabalho dentro da máquina. Isso é basicamente o que fazemos ao hospedar várias máquinas virtuais em um único servidor físico.