Por que os switches não reescrevem os endereços MAC?

Existe alguma razão específica para os comutadores Ethernet não alterarem o endereço MAC de um pacote?

É para identificação do host final usando o endereço MAC ou qualquer outra coisa?

Se um switch alterasse os endereços MAC, isso interromperia totalmente a rede.

O endereço MAC é um identificador exclusivo usado pelos hosts na rede local.

Se o switch alterasse o MAC de destino, o quadro não seria entregue ao host apropriado. Nos casos em que ocorreria, por exemplo, se o quadro fosse inundado, o host de destino o descartaria porque não seria mais destinado ao host.

Se o switch alterasse o endereço MAC de origem, o host de destino usaria esse endereço MAC para qualquer resposta (incluindo a atualização de entradas ARP com dados incorretos). Isso resultaria na mesma situação que eu já descrevi, apenas para todo o tráfego de retorno.

Isso poderia criar problemas com coisas como 802.1X e outros mecanismos que usam o endereço MAC para identificar / classificar o dispositivo.

Poderiam ser desenvolvidos mecanismos para fazer isso? Tenho certeza que eles poderiam. Mas não há razão para fazê-lo neste momento e isso apenas complicaria a rede e adicionaria processamento desnecessário. Não estamos perto de esgotar o pool de endereços MAC disponível, portanto não há necessidade de algo como MAT (não sei se o conceito de conversão de endereços MAC existe em algum lugar; talvez eu tenha cunhado um termo?).

A reconfiguração dos endereços dos datagramas ocorre na camada 3, por exemplo, quando os gateways (roteador ou firewall) executando NAT reescrevem os endereços IP dos hosts na rede interna, para que todos apareçam em um (ou alguns) endereços IP externos no próprio gateway.

A razão para algo semelhante não acontecer no nível da camada 2 (onde usamos endereços MAC para distinguir hosts e switches faz o movimento de datagramas, isto é, quadros) é como dito nos comentários acima, que realmente não há necessidade disso.

No caso da camada três com o NAT, o NAT resolve vários problemas:

• Os endereços IP são usados ​​para comunicação global e há um pool limitado de endereços IP disponíveis que precisa ser compartilhado. Ao usar o NAT, garante-se que um número maior de hosts internos possa compartilhar menos (normalmente apenas um) endereço IP visível na Internet pública.
• A reescrita de endereços IP é considerada por alguns, mas nem todos, para adicionar uma camada de segurança mascarando os endereços IP das máquinas internas.

Portanto, se mantivermos o exemplo do NAT, não haverá realmente necessidade de uma camada dois equivalente do NAT.

• Os endereços MAC não são usados ​​globalmente para endereçar datagramas na Internet, eles são usados ​​para enviar quadros aos hosts certos na sub-rede local. Como as sub-redes locais são relativamente pequenas e o número de endereços MAC possíveis é muito grande, não se "fica sem" os endereços MAC disponíveis no nível da camada 2. (A opção de reconfigurar manualmente os endereços MAC das NICs para um valor arbitrário não altera isso)
• E para o benefício de segurança discutível da reescrita de endereços de datagramas ao encaminhar: como os endereços MAC são usados ​​apenas em uma sub-rede local, geralmente é possível ter, em termos relativos, um controle muito melhor do ponto de vista da segurança sobre essa sub-rede (tanto fisicamente quanto na maioria das redes). dispositivos envolvidos) em comparação com a contraparte no caso da camada 3, que é toda a Internet (na qual nós, como usuários conectados e engenheiros de rede, na prática, não temos controle de segurança).

Espero que isso ajude a entender por que os switches não reescrevem os endereços MAC. O único caso da camada 3 que surgiu da parte superior da minha cabeça era o NAT, outros certamente podem fornecer exemplos de outros casos da camada 3 em que é necessário reescrever IP (e por que essas tecnologias realmente não fazem sentido no nível da camada 2) .

Reescrever o endereço MAC aumentaria uma complexidade considerável (o comutador precisaria conhecer protocolos de nível superior, como o arp, para reescrever a resolução do endereço), dificultaria a solução de problemas, impediria o funcionamento de protocolos como o STP e geralmente seria uma PITA. Normalmente, também não é necessário.

O que não quer dizer que não seja possível. O ebtables (a contraparte da camada 2 do iptables) tem algumas opções para conversão de endereços MAC. Isso pode ser útil se você tiver comutadores que não usem tabelas MAC por vlan e desejar fazer alguma filtragem da camada 2.

http://ebtables.netfilter.org/examples/example1.html