Since none of the primary protocol documents describe the forwarding
algorithm in any detail, we present it here. This is just a general
outline, and omits important details, such as handling of congestion,
that are dealt with in later sections.
It is not required that an implementation follow exactly the
algorithms given in sections [220.127.116.11], [18.104.22.168], and [22.214.171.124].
Much of the challenge of writing router software is to maximize the
rate at which the router can forward packets while still achieving
the same effect of the algorithm. Details of how to do that are
beyond the scope of this document, in part because they are heavily
dependent on the architecture of the router. Instead, we merely
point out the order dependencies among the steps:
A router MUST verify the IP header, as described in section
[5.2.2], before performing any actions based on the contents of
the header. This allows the router to detect and discard bad
packets before the expenditure of other resources.
Processing of certain IP options requires that the router insert
its IP address into the option. As noted in Section [5.2.4],
the address inserted MUST be the address of the logical
interface on which the packet is sent or the router's router-id
if the packet is sent over an unnumbered interface. Thus,
processing of these options cannot be completed until after the
output interface is chosen.
The router cannot check and decrement the TTL before checking
whether the packet should be delivered to the router itself, for
reasons mentioned in Section [126.96.36.199].
More generally, when a packet is delivered locally to the router,
its IP header MUST NOT be modified in any way (except that a
router may be required to insert a timestamp into any Timestamp
options in the IP header). Thus, before the router determines
whether the packet is to be delivered locally to the router, it
cannot update the IP header in any way that it is not prepared