At every layer of the protocols, there is a general rule (from [TRANS:2] by Jon Postel) whose application can lead to enormous benefits in robustness and interoperability:
Software should be written to deal with every conceivable error, no matter how unlikely. Eventually a packet will come in with that particular combination of errors and attributes, and unless the software is prepared, chaos can ensue. It is best to assume that the network is filled with malevolent entities that will send packets designed to have the worst possible effect. This assumption will lead to suitably protective design. The most serious problems in the Internet have been caused by unforeseen mechanisms triggered by low probability events; mere human malice would never have taken so devious a course!
Adaptability to change must be designed into all levels of router software. As a simple example, consider a protocol specification that contains an enumeration of values for a particular header field - e.g., a type field, a port number, or an error code; this enumeration must be assumed to be incomplete. If the protocol specification defines four possible error codes, the software must not break when a fifth code is defined. An undefined code might be logged, but it must not cause a failure.
The second part of the principal is almost as important: software on hosts or other routers may contain deficiencies that make it unwise to exploit legal but obscure protocol features. It is unwise to stray far from the obvious and simple, lest untoward effects result elsewhere. A corollary of this is watch out for misbehaving hosts; router software should be prepared to survive in the presence of misbehaving hosts. An important function of routers in the Internet is to limit the amount of disruption such hosts can inflict on the shared communication facility.