Middleboxes vs. the Internet's End-to-End Principle 90
arglebargle_xiv writes "The Internet was designed around the end-to-end principle, which says that functionality should be provided by end hosts rather than in the network itself. A new study of the effect of vast numbers of middleboxes on the Internet (PDF) indicates that this is no longer the case, since far too many devices on the Internet interfere with traffic in some way. This has serious implications for network (protocol) neutrality (as well as future IPv6 deployment) since only the particular variations of TCP that they know about will pass through them."
Re:What (Score:5, Informative)
Basically, whenever the pipes become smart, things overall become less reliable. It's simple math. Add one component along a network path, and now every app that uses the path may have to be fixed to cope with the new behaviour on that path. For example, if your ISP adds an HTTP filter, every app using HTTP is at risk of breaking the next day.
With end-to-end, the only correct place to put the new functionality (HTTP filtering in this example) is at an end, namely as a process on a user's computer. Now, the simple math works out: the user is filtered (same outcome as above), but the pipes are dumb and the only thing breaking due to the filter are programs on that user's computer. Everybody else's software works fine just as before.
Re:What (Score:5, Informative)
Even the term TCP/IP in itself is misleading. TCP and IP are two separate protocols. TCP is designed to be run on top of IP, and TCP does have some knowledge of the underlying protocol (a bit too much some would say). IP on the other hand has no knowledge of TCP. The IP header contains an 8 bit protocol field, so you can in principle run 256 different protocols on top of it (some values are reserved, and not all the other values are assigned yet). An implementation of IP does not have to implement all the higher level protocols, in fact only ICMP is mandatory.
A router is supposed to work on the IP layer. A router should not know about TCP, and it shouldn't care what protocols are run over it. In practice routers do tend to have TCP and UDP implementations as well. They have TCP because that is what is typically used to configure the routers, and BGP is run over TCP as well. And in some cases you may want to do DNS lookups, and for that you want UDP.
When you build a router you have to keep the right layering. The low level should do routing and not care about UDP and TCP. The next level can do TCP and UDP, and on high end routers the separation should be to the point where this is even implemented by a different piece of hardware from the one that does the routing. The next level up the stack can handle configuration and routing protocols. This layer can then push updated routing tables to the actual hardware doing the routing. If the different pieces stick to their area of responsibility, things will work out. All of those higher levels could in principle be implemented by a computer next to the router and leave the router to do only routing.
Some routers have features to interpret higher level protocol headers such as UDP and TCP and mangle them. Once it starts doing that, it is no longer a correct implementation of IP according to the original spec. The network is supposed to get the higher level payload from source to destination without mangling it. The network as it looks today fails at that task.
Routers do. They have to decrement the TTL, and in case of IPv4 adjust the header checksum. But most of the other fields in the IP header are read-only for the routers, and the higher level protocol headers such as UDP and TCP are totally off-limits.