¿Por qué los interruptores no reescriben las direcciones MAC?

¿Hay alguna razón particular por la cual los conmutadores Ethernet no cambian la dirección MAC de un paquete?

¿Es para la identificación del host final utilizando la dirección MAC, o cualquier otra cosa?

Si un conmutador cambiara las direcciones MAC, esto rompería la red por completo.

La dirección MAC es un identificador único que utilizan los hosts en la red local.

Si el conmutador cambiara el MAC de destino, la trama no se entregaría al host apropiado. En los casos en que lo haría, por ejemplo, si el marco se inunda, el host de destino lo descartará porque ya no estará destinado para el host.

Si el conmutador cambiara la dirección MAC de origen, el host de destino usaría esta dirección MAC para cualquier respuesta (incluida la actualización de cualquier entrada ARP con datos incorrectos). Esto daría como resultado la misma situación que ya describí, solo para todo el tráfico de retorno.

Esto podría crear problemas con cosas como 802.1X y otros mecanismos que usan la dirección MAC para identificar / clasificar el dispositivo.

¿Se podrían desarrollar mecanismos para hacer esto? Estoy seguro de que podrían hacerlo. Pero no hay ninguna razón para hacerlo en este momento y esto solo complicaría las redes y agregaría un procesamiento innecesario. No estamos cerca de agotar el conjunto de direcciones MAC disponibles, por lo que no hay necesidad de algo como MAT (no sé si el concepto de traducción de direcciones MAC existe en algún lugar, ¿tal vez acabo de acuñar un término?).

La reescritura de direcciones de datagramas ocurre en la capa 3, por ejemplo, cuando las puertas de enlace (enrutador o firewall) que ejecutan NAT reescribe las direcciones IP de los hosts en la red interna para que todas aparezcan desde una (o algunas) direcciones IP externas en la puerta de enlace.

La razón de que algo similar no suceda en el nivel de capa 2 (donde usamos direcciones MAC para distinguir hosts y conmutadores que hacen el movimiento de datagramas, es decir, marcos) es como se dijo en los comentarios anteriores que realmente no es necesario.

En el caso de la capa tres con NAT, NAT resuelve una serie de problemas:

• Las direcciones IP se utilizan para la comunicación global, y hay un conjunto limitado de direcciones IP disponibles que deben compartirse. Al usar NAT, uno se asegura de que un mayor número de hosts internos puedan compartir menos (comúnmente solo una) dirección IP visible en Internet público.
• Algunos, pero no todos, consideran que la reescritura de direcciones IP agrega una capa de seguridad al enmascarar las direcciones IP de las máquinas internas.

Entonces, si nos atenemos al ejemplo de NAT, realmente no hay necesidad de una contraparte de NAT de la capa dos.

• Las direcciones MAC no se usan globalmente para direccionar datagramas en Internet, se usan para enviar marcos a los hosts correctos en la subred local. Como las subredes locales son relativamente pequeñas y la cantidad de direcciones MAC posibles es muy grande, no se "agotan" las direcciones MAC disponibles en el nivel de capa 2. (La opción de reconfigurar manualmente las direcciones MAC de las NIC a un valor arbitrario no cambia esto)
• Y para el beneficio de seguridad discutible de reescribir direcciones de datagramas al reenviar: como las direcciones MAC se usan solo dentro de una subred local, generalmente se tiene, en términos relativos, un control mucho mejor desde una perspectiva de seguridad sobre esa subred (físicamente y la mayoría de las dispositivos involucrados) en comparación con la contraparte en el caso de la capa 3, que es todo el Internet (que nosotros como usuarios conectados e ingenieros de redes en la práctica no tenemos control de seguridad).

Espero que esto arroje algo de luz sobre por qué los conmutadores no reescriben las direcciones MAC. El único caso de capa 3 que se me ocurrió desde la parte superior de mi cabeza fue NAT, otros ciertamente pueden proporcionar ejemplos de otros casos de capa 3 en los que se justifica la reescritura de IP (y por qué esas tecnologías realmente no tienen sentido en el nivel de capa 2) .

Reescribir la dirección MAC agregaría una complejidad considerable (el conmutador debería conocer protocolos de nivel superior como arp para poder reescribir la resolución de direcciones), dificultaría la resolución de problemas, evitaría que protocolos como STP funcionen y, en general, sería un PITA. Tampoco se necesita normalmente.

Lo que no quiere decir que no sea posible. ebtables (la contraparte de la capa 2 de iptables) tiene algunas opciones para la traducción de direcciones MAC. Esto puede ser útil si tiene conmutadores que no usan tablas MAC por vlan y desea realizar un filtrado de capa 2.

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