Re: Minutes of MTU Discovery Working Group Meeting (7 Feb 1990)

[mogul (Jeffrey Mogul)]

    >	...there are 3 unused in the TOS field...
    
    Looking at the IP spec, I see only two unused bits (6 and 7).  Where is
    the third?

That's what I get for not checking the spec myself when I wrote up the notes.
    
    >	Within "a few" years, the routing protocols will provide
    >	path-MTU information, so MTU discovery will be unnecessary.
    
    This keeps popping up.  Would someone please explain this in more
    detail?  Exactly how are the routing protocols going to maintain or
    acquire the path-MTU information that hosts need, and how are the hosts
    going to learn that information and detect changes in that information?

Link-state routing protocols could carry the MTU as part of the link
state.  Thus, the routers could calculate the Path-MTU from their
link-state database.  Perhaps they could even make Max-MTU a separate
type-of-service (i.e., do you want minimal hop count or maximum MTU?)

As Craig points out, with multi-level routing protocols and information
hiding, it might be impossible to calculate the Path-MTU end-to-end.
I suppose this same sort of problem must afflict other type-of-service
routing (e.g., how does the system deal with "I want a secure route
end-to-end"?) and so presumably it could be solved in a similar manner.
Or maybe not, I'm trying to stay ignorant of routing protocols until
the fur stops flying.

How do the hosts use this info?  Clearly not by keeping the link-state
database; presumably, one could ask a default gateway (i.e., one on
the same LAN) for the MTU to the destination host (e.g., define an
"ICMP What's My Line?" message that returns the end-to-end link
state information for a destination).

    I believe that under 4.3BSD and derivatives (e.g., recent versions of
    SunOS and Ultrix), the RF bit does not survive fragmentation.  That is,
    if a datagram must be fragmented, the initial fragment ends up with a
    zero RF bit, regardless of that bit's value in the original datagram.

Hmm.  My reading of the code suggests that the RF bit is properly copied,
and I think Van and Mike Karels agreed.  Can you show which lines are
to blame?  In ip_output.c, I see the line
		mhip->ip_off = ((off - hlen) >> 3) + (ip->ip_off & ~IP_MF);
which looks like it copies the bits except for MF (which is then filled
in on the following lines).

-Jeff