I've had some clarifying discussion with Joe off-list, but now getting
back on so if others have opinions, those can be heard.
As for the earlier note on the list, IMHO RFC 2003 section 5.1 touches
only very cursorily from on the subject (some of the respective text
is in my draft in sections 3.1 and 3.2); this offers much more
extensive discussion.
On Wed, 3 Aug 2005, Joe Touch wrote:
[Joe about implementations which mistreat DF bit]
Just because people break spec doesn't mean that we need to consider
supporting it; that would require revising the requirements as a
starting point.
[PekkaS]
My draft doesn't try to support this option. It just isn't in denial
that such doesn't happen. There are plenty of tunnel implementations
which have options to clear or otherwise modify the inner bits. IMHO
it's OK to mention them (with a disclaimer, as the draft has done).
That also should lead the IETF to consider whether there is something
wrong, i.e., why people implement and find these features useful, and
whether those options break something else (e.g., PMTUD). But that's
out of scope of my draft.
Sec 2 of your doc notes ignoring the DF bit, but doesn't indicate that's
a standards violation.
OK, I'll replace the note "(unless the implementation ignores the DF
bit)" with "(see Section 3.4 for more)".
Sec 3.2 says IPv4 allows 2 options (notably this is RFC2003 that specs
that - but that's the other issue of citing the primary doc on
tunneling), where 'allows' should be 'is required by a standard'.
(Well, the predecessor of a predecessor of a predecessor of (referred)
draft-ietf-mech-v2, RFC 1933, is AFAICS the first standards track doc
to describe this.)
I don't think "is required" is correct or I don't understand what you
refer to with "required". RFC 2003 says,
Thus, the encapsulator SHOULD normally do Path MTU Discovery,
requiring it to send all datagrams into the tunnel with the "Don't
Fragment" bit set in the outer IP header.
SHOULD is not a MUST (earlier, the RFC does mandate implementation of
PMTUD, but as said, doesn't mandate its usage). Similarly,
draft-ietf-mech-v2 and its predecessors allow the implementors and/or
users to choose non-DF approach as well, if they judge it appropriate.
Sec 3.4 "regardless of what the specifications say" is a glib (IMO) way
to express "there are existing implementations that violate the standard
that..."
I've changed this to:
<t>However, there are existing implementations that
violate the standard that:</t>
Later sec 3.4 says "but there are certainly uses for it". IMO, that's
endorsement, and I disagree. It doesn't "work around" PMTUD issues, but
rather defeats PMUTD. If there is indeed a justifiable reason to
consider this option, it should be explained in this document, as it is
key to whether it should be considered anything other than broken (or
are you also allowing stacks that miscalcuate the IP checksum, just
because some do? :-)
I think the most compelling case has been described in section 3.1 --
when having tunnels (especially IPsec tunnels, but any tunnel is the
same) over which a large amount of traffic is being transported, where
PMTUD is too unrealiable or unfeasible as noted in section 3.2.
In this case, reassembly becomes a problem (requires basically
infinite buffers, problems when a fragment goes missing, v4 ID space
is insufficient so it wraps over and causes data
corruption/misassociation, etc. -- see section 3.1).
So, it just isn't possible to do a [v4] high-bandwidth tunnel with
fragmentation/reassembly; I guess the point is whether the reasons why
you can't use PMTUD are convincing enough (e.g., would have to be done
to millions of sources, passive monitoring, etc.)
In particular, clearing the DF bit may disable downstream path
discovery, BUT the discussion implies it should be done only for
already-fragmented packets. A packet which is fragmented with the DF bit
set is an error and should be dropped, since it was a don't fragmented
and has been fragmented, as noted in RFC791 (see page 8).
I.e., this example is nonsensical; if there is a valid one, it would be
useful to present it.
No, the discussion tries to point out that if the implementation
clears the inner DF bit (and consequently causes fragmentation for big
packets at the same node), even if further downstream the packets
would get fragmented _again_, that further fragmentation doesn't make
matters any worse.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
