>From Pekka Savola <[EMAIL PROTECTED]>: ... >> I've had some clarifying discussion with Joe off-list, but now >> getting back on so if others have opinions, those can be heard.
(this is where I thought we were waiting)... - was there other input?
>> 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.
I disagree; actually, I believe that 2003 is both complete and
sufficient on the subject, so I'm not sure what the purpose of an
additional draft discussing the same issue in other contexts is.
>> 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.)
1933 doesn't spec v4 in v4 tunnels; 2003 does (as per numerous 'who owns
what protocol ID docs').
Again, since you're talking about IP in IP tunnels, 2003 is the current
core standard. You can certainly cite others, but 2003 seems manditory.
>> 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.
It says:
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.
There's a MUST there ;-)
>> 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.
2003 would override draft-ietf-mech-v2 esp. regarding v4 in v4 tunnels;
I know of no effort to override 2003 yet.
>>>> 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.
This is just making a decision at the tunnel that you prefer efficiency
to PMTUD support. 2003 doesn't say it's OK to make that decision, esp.
since it's not detectable from the endpoints. I don't think this is a
compelling reason, as a result.
>> 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).
Reassembly doesn't require infinite buffers; the fragments need be held
only for a network MSL, and the IP ID numbers are required not to wrap
during that period, so there's no wrap problem if everybody stays to spec.
It's equally possible to just limit reassembly buffers and toss old
fragments earlier than a network MSL; it just increases the error rate
of the 'link' provided by the tunnel.
>> 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.)
Yes, it is not possible to do high bandwidth frag/reassembly, period,
regardless of whether it's a tunnel or not. We may need to address this,
or not - but breaking PMTUD is a bad way to do so, since it would
increase fragmentation. The whole point of PMTUD is to discover the MTU
size to avoid inefficient (esp. for high bandwidth paths) sizes;
deciding to violate 2003's requirements for DF copying just to support
high bandwidth frag/reassy (which won't work anyway) is very illogical.
>>>> 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.
A packet with the DF bit set with MF also set is an error as per RFC791.
The discussion implies that this can exist - or are you talking about
clearing only the outer DF?
Joe
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
