On 02 Aug 2013, at 03:58 , Ronald Bonica wrote: > Furthermore, we can now make clear that the two following > statements regarding *New* applications offer practical > alternatives. > > These are: > a) PMTUD/PLMTUD > and b) short PDUs
Agree. I am reluctant to say that any of those are sufficient in all deployments, because there are too many IPv6 deployments to evaluate, but clearly each of those mechanisms can be useful. > How about: > MUST support PMTUD and SHOULD support PLMTUD, > just in case ICMP PTB is filtered. Fine. "MUST support PMTUD" and "SHOULD support PLMTUD". >> I would change s/MUST NOT/SHOULD NOT/. >> >> I'd delete the phrase "of 1280 bytes" as well, mainly because it is >> redundant, and partly so that this BCP would not need updating if the >> 1280 number changed in future. (It has already changed from >> unspecified to 576 to 1280 over time.) > > I think that MUST is OK, so long as we are clear that we are talking > about an application for which IP fragmentation has already been > ruled out. I'd like to read the draft text in an I-D first. > I would say that ICMP PTB messages MUST never be blocked, > even if the MTU is small. RFC 2460 specifies one corner case > where the MTU can be small. Agree. Fernando has identified some scenarios where the advertised MTU will be smaller than 1280. Additionally, I've seen some other real-world scenarios where it happens. So, I'd suggest that the document outline several scenarios where the MTU can be small, so that implementers and operators reading the document will realise that smaller MTUs can appear in the wild. > Yes. Currently the section on Tunnels contains one word of text, > "TBD". I will fix that in the next revision. >From an implementation perspective, most often it is expensive & complex for a tunnel endpoint reassemble transit fragments. In the current global Internet, few router implementers are comfortable trying to reassemble anywhere in the middle of the path, in part because of the additional attack surface that reassembling transit traffic would create. Instead, at tunnel egress, any fragments are likely to be merely decapsulated and then forwarded. So, it is critical that end systems be able to reassemble fragments as fragments will continue to exist in the real world. Yours, Ran -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
