![]() ![]() (Keep in mind that many IPv4 stacks do not allow multiple IP addresses per interface, so assigning both the public and local addresses would not be an option.) In contrast, the translation that's done For example, if you just directly assigned the same public IP address to all LAN hosts as well as the router – making them accept unmodified packets, with the public IP address – the devices couldn't speak to each other anymore, due to all of them having the same address. There may have been other ways of achieving similar kinds of "sharing" an IP address between multiple devices, but they would have required changes to the devices themselves. The result is that the target device thinks it is indeed the destination of the "forwarded" connection and doesn't get confused by receiving a packet with the router's IP (which it would normally discard – or worse, forward back to the router). In other words, the IP address needs to be provided because the entire point of "port forwarding" as opposed to plain routing is to put the target device's IP address in the packet. But the more important reason is because "port forwarding" was a much later addition to IP networking, so it's implemented in such a way that the final host doesn't need to be aware of it happening: unlike with plain routing, a "port-forwarded" packet's actual destination IP address (the one in the IP header) is translated from the router's WAN address to the internal address that you specify. The origin gateway's OS simply uses NDP instead of ARP to resolve the nexthop gateway's MAC address, without any changes to the actual IPv4 packet being forwarded.)įor "port forwarding" a few of the same reasons apply, such as the ability to separate an IP address from the physical host. (But some networks actually use IPv6 nexthop addresses for IPv4 network routes. Also, despite the additional translation, it simplifies things because it means all packets are handled the same way whether they're being delivered to the final host or to another gateway, instead of there being two different cases. So it's actually simpler to accept IP addresses and rely on the existing mechanisms to translate them – mechanisms such as ARP that need to be present anyway. ![]() Even a typical home gateway is not built purely with Ethernet in mind: an ADSL modem already has to deal with two entirely different MAC layers, so its routing table would need to accept two different nexthop address types. For one, using an IP address is a useful abstraction, thanks to the use of ARP (or NDP) for dynamically resolving the MAC addresses: the actual gateway can change its Ethernet interfaces, but as long as it assumes the same IP address, the same old routing configuration stays valid.Īnother reason is that it's simpler to accept just one address type instead of multiple. ![]() What you've described is actually very close to how IP routing works behind the scenes – when NAT or "port forwarding" is not involved, a router forwards packets by changing just their destination MAC and technically doesn't need to know the IP address of the device.įor example, in the routing table (by which I do not mean the "port forwarding" rules) you have a "gateway" or "next hop" field which is traditionally an IP address, but its only purpose is to be resolved to some kind of lower-layer address, so the routing table could perfectly well accept a MAC address directly.īut despite that, routing table entries require an IP address for various reasons. I just mean it for the identification purpose. I know this is not how it works, the question is why it wasn't implemented like this in the first place? And yes, a frame is not a packet anyway. On the router, I forward the port 80 (external) to the port 80 (internal) of (instead of the local IP) the MAC address of the PC.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |