Hi Ron, > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Ronald Bonica > Sent: Tuesday, July 30, 2013 1:34 AM > To: Randy Bush; Bob Hinden > Cc: IPv6 Maintanence; Fred Baker (fred) > Subject: RE: "Deprecate" > > Folks, > > I think that we heard the following at yesterday's meeting: > > Title > ===== > The document should be renamed "IPv6 Fragmentation Considered > Ineffective"
I disagree with any name of the form "Fragmentation Considered X"; otherwise, I would have called my doc "Fragmentation Considered Useful". The "X Considered Y" naming convention came from Dijkstra's "Go To Considered Harmful", but gotos are still widely used, e.g., in operating system kernel code. Plus, I personally find any use of "X Considered Y" to be a copycat cliché. > 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 > > > 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 > ---*New* applications and transport layer protocols SHOULD support > effective PLMTUD [RFC4821] since ICMP-based PMTUD [RFC1981] is > unreliable > --*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. > > - Legacy applications and transport layer protocols will continue to > generate fragments > --- In the interest of backwards compatibility, IPv6 stacks and > forwarding nodes MUST continue to support inbound fragmented IPv6 > packets as specified in [RFC2460]. > > - 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. > --- Therefore, if a legacy protocol is capable of breaking its > dependence on IPv6 fragmentation, it should consider doing so. > > > Did I miss anything? You missed tunnels. The tunnel has no way of knowing whether the source host is doing RFC4821-style probing, so it has no way of knowing when to drop vs forward. All it knows is that it MUST pass packets of at least 1280 bytes (the IPv6 minMTU), and SHOULD also pass packets of at least 1500 bytes (the minimum size most hosts expect). For that, it needs some form of fragmentation and reassembly, and if you want to deprecate IPv6 fragmentation you need to replace it with something like SEAL. Thanks - Fred fred.l.temp...@boeing.com > Ron > > > > > > hmmm. i am gonna put my foot in the cow pie. > > i think what we want here is something close to > > o future implementations SHOULD not generate frags > > (note that SHOULD != MUST) > > o expect to receive frags for a long time > > > > randy > > > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
