Re: DF bit processing in tunnelling devices

[Jason R Thorpe <thorpej%zembu.com@localhost>]

On Thu, Jul 06, 2000 at 06:59:05AM +0900, itojun%iijlab.net@localhost wrote:

 > >    syssrc/sys/netinet: in_gif.c
 > >Log Message:
 > >RFCs 1853, 2003, 2401 -- copy the DF bit.
 > 
 >      i'm not 100% sure if we should do this or not.
 >      RFC2401 says that the DF bit behavior should be configurable
 >      (copy, zero-clear, or set) in 6.1.1.  appendix B has more meat.
 > 
 >      with "copy" behavior, you will see more ICMP too big message, which
 >      can choke in environment with icmp filtered (bad practice, but
 >      we see too many of this).  good thing is that we can get better
 >      performance if everyone does path MTU discovery right.
 >      - your tunnel router got 1500bytes of native IPv4 packet, with
 >        DF bit set
 >      - gif_output encapsulates it, copy DF bit (now 1520bytes)
 >      - ip_output chokes and sends ICMP too big message

Right, Tunnel MTU Discovery is that RFC 1853 calls it.  2003 is also
pretty explicit (uses MUST) about what needs to happen with DF.

RFC 1853, page 4:

   Don't Fragment   copied from the inner IP header.  This allows the
                    originator to control the level of performance
                    tradeoffs.  See "Tunnel MTU Discovery".

...

3.1.  Tunnel MTU Discovery

   When the Don't Fragment bit is set by the originator and copied into
   the outer IP header, the proper MTU of the tunnel will be learned
   from ICMP (Type 3 Code 4) "Datagram Too Big" errors reported to the
   encapsulator.  To support originating hosts which use this
   capability, all implementations MUST support Path MTU Discovery
   [RFC-1191, RFC-1435] within their tunnels.

RFC 2003, page 4:

      Identification, Flags, Fragment Offset
   
         These three fields are set as specified in [10].  However, if
         the "Don't Fragment" bit is set in the inner IP header, it MUST
         be set in the outer IP header; if the "Don't Fragment" bit is
         not set in the inner IP header, it MAY be set in the outer IP
         header, as described in Section 5.1.

I guess the right way to view this is a sort of `forwarding', and
normal Internet routers also copy DF.  It's really no different than
having a non-encapsulating router forward a DF'd packet out a small-MTU
PPP interface.

-- 
        -- Jason R. Thorpe <thorpej%zembu.com@localhost>