Re: Mods to Steve Deering's "DF" scheme

mogul (Jeffrey Mogul) Thu, 08 March 1990 18:49 UTC

Received: by (5.54.5/4.7.34) id AA11024; Thu, 8 Mar 90 10:49:35 PST
From: mogul (Jeffrey Mogul)
Message-Id: <>
Date: 8 Mar 1990 1049-PST (Thursday)
To: (John Moy)
Cc: mtudwg
Subject: Re: Mods to Steve Deering's "DF" scheme
In-Reply-To: (John Moy) / Tue, 6 Mar 90 15:37:10 EST. <>

    Go ahead and use the extra bit in the flags field. We're fixing this
    as I write (although you might want to check with the other vendors -
    my (old) IP specification still says that this bit MUST be 0), and by
    the time you guys start deploying MTU discovery people should have the
    updated Proteon software installed.
Well, although the IP spec says "MUST be 0", it also says elsewhere
that "an implementation ... must be liberal in its receiving behavior.
... [it] must accept any datagram that it can interpret (e.g., not
object to technical errors where the meaning is still clear)."

However, I think you're right that it would be a good idea to check
to make sure that there aren't other routers which drop such packets.
To that end, I did a little experiment: I changed the code in ip_output.c
in my Ultrix kernel (but this should be applicable to anything even
vaguely derived from 4.2BSD):

    *** 79,80
      struct mbuf *ip_insertoptions();
    --- 79,84 -----
    + #ifdef        RFTEST
    + int rftest = 0;               /* if set, then set the "RF bit" in originated p
    kts */
    + #endif        RFTEST
      struct mbuf *ip_insertoptions();
    *** 108,109
		    ip->ip_off &= IP_DF;
		    ip->ip_id = htons(ip_id++);
    --- 112,117 -----
		    ip->ip_off &= IP_DF;
    + #ifdef        RFTEST
    +               if (rftest)
    +                   ip->ip_off |= 0x8000;       /* set the "RF bit" */
    + #endif        RFTEST
		    ip->ip_id = htons(ip_id++);

Your line numbers will vary, of course.

Anyway, now I can control the "send RF" behavior by using adb
(or an equivalent) to set/clear the "rftest" global flag.  I
find that one of the BARRNET routers fairly close to me drops
these packets; I'm trying to find out what kind of router it

Since I can't get very far with these packets, I encourage
other people to put together a modified kernel and run
a few traceroutes ... if we find non-Proteon routers that drop
these packets, we should let people know ASAP.