One piece of potentially important information: PMTUD and PLMTUD are intended to avoid the need for on-path fragmentation. That's why there is control only over the DF bit, not source fragmentation.
AFAICT, this points to a (AFAICT) a problem with IPv6 PMTUD as described in RFC1981. That doc claims to try to optimize to the native link MTU, but that doesn't appear to be possible given the way IPv4 and IPv6 interact with transports. There's no signal to IP that says "don't source fragment". Joe On 12/14/2016 11:12 AM, Joe Touch wrote: > Hi, Gorry, > > Let me see of I can explain my viewpoint. > > I'll start by noting that there's a difference between "what transports > currently do" and what they "should" do. I agree with you that current > transports do have access to network MTUs and DF control, but don't > always pass all that to the user. > > Here's what I think is currently required: > > 1122 indicates the interface between IP and transport as indicating the > max send and receive transport sizes - but for IPv6 that would be 1500 - > IPheaders, not 1280 - IP headers or even 1500 or 1280. > > 1122 also indicates that the transport - not the application - gets to > set DF in the SEND call to IP. > > However, there does not appear to be any provision to limit source > fragmentation between transport and IP, nor any requirement for UDP to > pass that control to the app. > > ---- > > So 1122 is consistent with my view that: > > - the application sees a transport MSS (I'm not sure whether to call > that max or native yet...) > > - the transport sees the max network MSS (i.e., allowing source > fragmentation), not the native network MSS > > I don't understand why 1122 requires transport control over DF, but UDP > is not required to pass that control to the user. > > --- > > My conclusion is that the app-transport API *should* be required to give > the user control over whether to use the max or native transport MSS, > just as the transport-API should be required to give the transport > control over whether to use the max or native network MSS, and so forth > for the network-link API. > > However, none of that implies that the user ever will be able to match > the link MTU. There's always the possibility that one of these layers > decides to never report a true native size, e.g., ATM (as a link layer) > never reports 48 to IP. > > This means that apps can't ever really force a probe of much of > anything, too. Only transports can. > > (FWIW, when I say that UDP doesn't support fragmentation, I mean that > UDP doesn't have UDP fragmentation. The fragmentation is at the IP > layer; UDP is ignorant of it). > > Joe _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
