(For example, that's more or less how ATM 'switches' worked – ATM was one of the competing network technologies, and had much tighter integration between L2 and 元.)īut these days it's big change really not worth making, perhaps because the protocols you mention are "de facto standard" – the deployment base of existing Ethernet LANs is so massive that making such changes would be impossible, considering the minimal gains in performance. You could indeed do this if you were designing the entire stack from ground up. Private IP addresses can also be unique, the fact it changes when being moved around doesn't really matter for the success of routing.Īre there any other good reasons for the MAC address to be used for routing? Last, I hear the argument that "MAC address is globally unique", but I don't think it has much to do with routing. However, I don't know if it makes sense for the majority of the use cases to cater to these minor cases, by paying the seemingly unnecessary overhead of ARP. If we route everything via private IP address only, then everything needs to be connected directly to a router, which is typically more expensive than a link layer switch.Īlso, there may be less common non-IP 元 protocols still in use, where Ethernet is running underneath. The only good reason I can think of is cost. Then I want to ask: why the hassle? why cannot we just use IP address to deliver packets to another machine on the same Ethernet? The link and internet layer are not "separated" at all, the only thing MAC address bought to the process is the ARP overhead. However, my understanding is that nowadays Ethernet is the de-facto link layer protocol, but on the same Ethernet, we are still communicating via private IP address! Moreover, that private IP address has to be translated to a MAC address via ARP protocol. When back in the 90s there were multiple competing link layer protocols, it might have made sense for this separation. I understand the benefit of layering in network protocols and the "separation between link layer and IP layer".
0 kommentar(er)
