> If packets going into the device are retransmitted in any way, the device is "routing" packets. Dumb retransmitting/repeating packets ix a type of routing, even if it isn't making important decisions about each packet.
A hub is not a router. An inline repeater is not a router. That is not a normal or useful definition.
> flowchart
When most people talk about routing, I think they mean the boxes you labeled [Packet Router]. A NAT-only device would basically remove every conditional box, remove every box labeled [Firewall], and remove every box labeled [Packet Router].
Packet received -> Rewrite headers -> Packet output.
Technically you'd have two identical flowcharts, one for each direction.
> If-and-only-if you had that unusual NAT-only, no-firewall device - which is very different from a typical home router - it could route packets to your private LAN if they were addressed to a valid LAN address (perhaps 192.168.1.x?).
Any packet coming in from the internet would hit the rewrite engine, the rewrite would fail, and it would not make it to the LAN.
> They would bypass NAT and be routed to the LAN, just like the router's own communication with the LAN. You wouldn't expect NAT to touch packets sent from the router's management HTTP server to a host on the internal/private LAN.
If you had to have a web interface, then packets coming from the NAT device itself would be sent directly to the port, not to the NAT engine.
But for this thought experiment let's just not have a web interface.
> The malicious packet might be sent from something like a smart TV" that you "isolated" in a 2nd LAN or DMZ connected to the same router.
Packet from a LAN? It gets NAT applied and goes to the internet. The internet can decide what to do with a destination of 192.168.0.107
(I would have said you can't even have two LANs without routing, but you could force it to happen, like making every WAN->LAN packet go out to both of them.)
All these attacks you're listing are using routing to bypass the NAT functionality. Not possible in a device that cannot route.
> Changing the SRC Address field in the header is routing the packet!
That is an interesting and pretty convincing argument. Two caveats, though. One is that this is still a separate thing from "packet routing" or whatever you want to call picking a direction/vlan for a packet to go to based on routing tables.
The other caveat is that it might just be imprecise language. What if "by" means "by also". They are assuming you have a normal router as a base, are making it transparent by adding header modification. So then transparent routing is a combination of routing and header modification, but header modification all by itself is not routing.
Because the RFC assumes you started with a router, maybe I should say "just the Network Address Translation portion of the NAT RFC" instead of "NAT", but that seems like an unnecessary level of pedantry.
A hub is not a router. An inline repeater is not a router. That is not a normal or useful definition.
> flowchart
When most people talk about routing, I think they mean the boxes you labeled [Packet Router]. A NAT-only device would basically remove every conditional box, remove every box labeled [Firewall], and remove every box labeled [Packet Router].
Packet received -> Rewrite headers -> Packet output.
Technically you'd have two identical flowcharts, one for each direction.
> If-and-only-if you had that unusual NAT-only, no-firewall device - which is very different from a typical home router - it could route packets to your private LAN if they were addressed to a valid LAN address (perhaps 192.168.1.x?).
Any packet coming in from the internet would hit the rewrite engine, the rewrite would fail, and it would not make it to the LAN.
> They would bypass NAT and be routed to the LAN, just like the router's own communication with the LAN. You wouldn't expect NAT to touch packets sent from the router's management HTTP server to a host on the internal/private LAN.
If you had to have a web interface, then packets coming from the NAT device itself would be sent directly to the port, not to the NAT engine.
But for this thought experiment let's just not have a web interface.
> The malicious packet might be sent from something like a smart TV" that you "isolated" in a 2nd LAN or DMZ connected to the same router.
Packet from a LAN? It gets NAT applied and goes to the internet. The internet can decide what to do with a destination of 192.168.0.107
(I would have said you can't even have two LANs without routing, but you could force it to happen, like making every WAN->LAN packet go out to both of them.)
All these attacks you're listing are using routing to bypass the NAT functionality. Not possible in a device that cannot route.
> Changing the SRC Address field in the header is routing the packet!
That is an interesting and pretty convincing argument. Two caveats, though. One is that this is still a separate thing from "packet routing" or whatever you want to call picking a direction/vlan for a packet to go to based on routing tables.
The other caveat is that it might just be imprecise language. What if "by" means "by also". They are assuming you have a normal router as a base, are making it transparent by adding header modification. So then transparent routing is a combination of routing and header modification, but header modification all by itself is not routing.
Because the RFC assumes you started with a router, maybe I should say "just the Network Address Translation portion of the NAT RFC" instead of "NAT", but that seems like an unnecessary level of pedantry.