Subject: Re: [Int-area] Recycle IPv4 bits

From: [email-masked] (Noel Chiappa)
Date: Fri, 1 Apr 2011 10:59:22 -0400 (EDT)

> From: Joe Touch <[email-masked]>

    > The source can fragment, though, and THEN set DF on the fragments.
    > ...
    > it can be changed from 0 to 1 by a router.

FWIW, I don't believe either of these cases was considered when we were
finalizing the IPv4 spec. If you read RFC-791, it's clear from the
discussion there of DF that it was intended to prevent fragmentation of
complete datagrams (e.g. for interacting with a host which could not do
reassembly, perhaps because it was a ROM bootloader with limited code
space), not further fragmentation of fragments. Before this discussion, I
would have considered a packet with DF=1 and Offset!=0 to be in error.

Which doesn't mean we _shouldn't_ allow them, but I'm pretty sure it was
never contemplated that it could/would be done.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 5 Apr 2011 17:00:53 -0400 (EDT)

> I can only conclude that the whole point of the too-big is to get
    > the source to fragment *at the source*.

Yes, that was our intention.

    > Source fragmentation definitely occurs when the outgoing message is
    > bigger than the interface supports

Yes. One of the earlier instances of this I can recall is Dave Clark
getting Multics to emit 65Kbyte TCP segments (although I think only other
Multices supported reassembling packets that large at that stage) - that
caused the TCP process to get woken up 'less often' on bulk data
transfers, and so gave him less overhead.

But, like I said, I don't think we ever envisaged a source host
fragmenting a packet and _then_ setting DF=1 on the fragments. DF was
there for packets you didn't wanted fragmented _at all_ - and for the host
to pre-fragment, and then set DF on the fragments, makes no sense at all
from that point of view.

In other words, had we thought of it, we'd probably have disallowed
sending packets with DF=1 and (Offset!=0 or MF=1).

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 5 Apr 2011 17:12:59 -0400 (EDT)

> From: [email-masked] (Noel Chiappa)

    > Yes, that was our intention.

Oops, minor thinko: now that I think about it, I think our intended response
was, for packets with DF set, for the source host to send smaller packets.
(And if the application could not do that, tough noogies - it then gets to use
fragmentable packets, or nada.)

Although I'm not sure that we gave this all that much thought, actually. I
suspect what happened is that we thought up every failure mode we could think
of, and defined an ICMP error code for it. We didn't think through in detail
how each one would be used/handled - case in point being Source Quench!
In this case, note that neither RFC 815 nor RFC 816 cover packets with DF set
- it just wasn't something we thought much about.

	Noel