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. 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. > 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./ > ---*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. > --*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.) 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. > - 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. 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. > --- 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. > - 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/ 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 --------------------------------------------------------------------
