Subject: Re: ip_flow.c
To: Kevin M. Lahey <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-net
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
   be logged.

   (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
        length field.

   A router MUST NOT have a configuration option that allows disabling
   any of these tests.

---- end quote