Inline.....
> -----Original Message----- > From: Fred Baker (fred) [mailto:f...@cisco.com] > Sent: Tuesday, July 30, 2013 10:42 AM > To: Ronald Bonica > Cc: Randy Bush; Bob Hinden; IPv6 Maintanence > Subject: Re: "Deprecate" > > I mostly agree. Some fuzz. > > On Jul 30, 2013, at 10:34 AM, Ronald Bonica <rbon...@juniper.net> > wrote: > > > Folks, > > > > I think that we heard the following at yesterday's meeting: > > > > Title > > ===== > > The document should be renamed "IPv6 Fragmentation Considered > Ineffective" > > "Ineffective" has to be modified by "for some specific purpose". Is it > ineffective at getting packets through end to end? Ineffective at > getting through firewalls? What? > How about "IPv6 Fragmentation Considered Ineffective for End-to-end Transport"? > > 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. > > I'm a little concerned by this. I understand it, I think, but ... > > So, then the IETF should not standardize RTP or any protocol (voice, > video, ...) that uses it, because RTP relies on its application to > manage frame size, and we can't say specifically what the codec will > do? s/RTP/UDP/? > Thinking a little more about it, RTP and UDP aren't the real culprits. The culprits are the applications that run over them. So, we should limit our statement to applications, and not "applications and transport layer protocols". Ron > > - 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. > > That I agree with. > > > Did I miss anything? > > > > 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 > > > > > > > > ------------------------------------------------------ > 8 issues in virtual infrastructure > http://dcrocker.net/#fallacies > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
