Hi Ran, Thanks for the review. Comments inline.....
> -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > RJ Atkinson > Sent: Thursday, August 01, 2013 4:35 PM > To: ipv6@ietf.org > Subject: Re: "Deprecate" > > On Tuesday 30th July, Ron Bonica wrote, in part: > > I think that we heard the following at yesterday's meeting: > > > > Title > > ===== > > The document should be renamed "IPv6 Fragmentation Considered > Ineffective" > > That is an improvement because it more accurately describes the content > of the draft. Agree. I think that we should go with Brian's proposed title. > > One might also consider a title that reframed it in terms of advice to > application designers. > > > Deprecation > > =========== > > All instances of the word "deprecate" should be removed from the > > document. > > > > Therefore: > > -- The document should not request any IANA actions > > -- The document doesn't UDPDATE 2460 > > -- The document doesn't need to be PS. BCP is good enough > > Agree with all of the above. > Either BCP or Informational is fine. Agree > > > Recommendation > > =============== > > The Recommendation section should be renamed "Conclusion". > > It should include the following statements: > > > > - The IETF SHOULD NOT standardize an new protocols that > > rely on IPv6 fragmentation > > I think we should allow the IESG/IETF more leeway to handle situations > currently unforeseen. > > So I would suggest an edit along these lines: > > s/rely on IPv6 fragmentation/rely on IPv6 fragmentation if a practical > alternative to fragmentation exists for that protocol./ Also agree. 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 > > > ---*New* applications and transport layer protocols SHOULD support > > effective PLMTUD [RFC4821] since ICMP-based PMTUD [RFC1981] is > > unreliable > > Neither approach is 100% reliable in the most general case. > > So, I'd suggest that new apps and transport-layer protocols SHOULD > support both PLMTUD and ICMP-based PMTUD. Supporting both enhances the > chances that some form of Path MTU Discovery will work for a given > session. > How about MUST support PMTUD and SHOULD support PLMTUD, just in case ICMP PTB is filtered. This statement would make most currently deployed TCP stacks compliant. So, if a new protocol runs over TCP, it is compliant. > > --*New* applications or transport layer protocols that cannot support > > effective PMTUD MUST NOT in any circumstances send IPv6 packets that > > exceed the IPv6 minimum MTU of 1280 bytes. > > 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. > > This document is all good advice, but I know of multiple IPv6 > deployments where PMTUD works quite well. If an application is > deployed in such an environment, and knows that it is (e.g. some > locally-developed application as different from a standard application > such as HTTP), then the application ought to be able to use the IETF > standards-track PMTUD mechanism without violating other IETF standards- > track specifications. Ack. > > > - Legacy applications and transport layer protocols will continue > > to generate fragments > > Since this is basically a document with lots of good advice, I'd also > add some very clear and specific recommendations that middleboxes and > firewalls: > > A) MUST NOT block ICMP-based PMTUD messages where the indicated > link MTU is equal-to or greater-than the standard IPv6 minimum > link MTU. > > B) SHOULD NOT block ICMP-based PMTUD messages where the indicated > link MTU is less than the standard IPv6 minimum link MTU in order > to avoid breaking real-world nested tunnel deployments using > IETF standards-track technologies. > 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. > > Discussion: > Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel-mode, > or some other IETF specified technology, are NOT going away. If > the physical MTU is 1280, then the tunnel MTU will be smaller. > Nested tunnels are not unusual and can be difficult to detect > absent a working PMTUD mechanism (whatever that might be). > > Tunnel-based deployments are just as real, and just as unlikely > to disappear, as the current issues with PMTUD deployments. The > document should be clear about this. Yes. Currently the section on Tunnels contains one word of text, "TBD". I will fix that in the next revision. > > > --- In the interest of backwards compatibility, IPv6 stacks and > > forwarding nodes MUST continue to support inbound fragmented IPv6 > > packets as specified in [RFC2460]. > > Yes. In particular, receiving hosts will need to continue to support > IPv6 fragment reassembly for sessions terminating at such hosts. Agree > > > - Implementers and operators need to be aware that on many paths > > through the Internet, IPv6 fragmentation will fail. Legacy > > applications and transport layer protocols that do not conform to the > previous paragraph can expect connectivity failures as a result. > > s/can expect/might experience/ OK Ron > > We don't want to use words that a naive reader/implementer would > misinterpret as consent for violating RFC-2460 et seq. > > > --- Therefore, if a legacy protocol is capable of breaking its > > dependence on IPv6 fragmentation, it should consider doing so. > > Agreed. > > Yours, > > Ran > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
