Subject: Re: ip_flow.c
To: Kevin M. Lahey <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 01/28/1999 23:57:25
I pretty much agree with Kevin about squeaky-cleanness. Serious IP
forwarding engines are getting compiled into ASICs (or microcode,
which is what Craig Partridge's forwarding engine is.:).
>I'd love to hear conflicting opinions (and I wasn't yet convinced
>that incremental checksum updating violated RFC1812, anyway).
Um, incremental checksum update is fine by rfc1812. Its not
validating the IP header checksum on receiption that violates RFC1812,
sec 5.2.2. (see below.). The language is pretty explicit.
BTW, the following discussion paragraphs are about checking IP length
(the m_pktlen check) , and about SSRR handling. RFC1812 says a rouer
should send an ICMP parameter problem, not bad source route, in
response to an SSRR not addresed to the router.
But our ip_dooptions() sends a bad source route ICMP. Worth fixing?
---- begin quote
5.2.2 IP Header Validation
Before a router can process any IP packet, it MUST perform a the
following basic validity checks on the packet's IP header to ensure
that the header is meaningful. If the packet fails any of the
following tests, it MUST be silently discarded, and the error SHOULD
(1) The packet length reported by the Link Layer must be large enough
to hold the minimum length legal IP datagram (20 bytes).
(2) The IP checksum must be correct.
(3) The IP version number must be 4. If the version number is not 4
then the packet may be another version of IP, such as IPng or
(4) The IP header length field must be large enough to hold the
minimum length legal IP datagram (20 bytes = 5 words).
(5) The IP total length field must be large enough to hold the IP
datagram header, whose length is specified in the IP header
A router MUST NOT have a configuration option that allows disabling
any of these tests.
---- end quote